Hi,
as a late follow-up, we ended up being like this:
@ValidationMethod
public void validateOnResolution( final ValidationErrors errors ) {
rest().validateFor( "GET", new Runnable() {
/** {@inheritDoc} */
@Override public void run() {
if( w
Joaquin,
Since there are so many different ways people do
authentication/authorization, I didn't build any kind of authentication
into it for those reasons.
I've personally done it a couple of different ways using this REST
framework. One was BASIC auth and another way was actually writing an
Au
Supporting Apache Shiro (which I highly recommend; it’s really good) in any
Stripes app is pretty easy:
http://www.ecyrd.com/ButtUgly/wiki/Main_blogentry_100910_1
You can then e.g. have your own Interceptor or actionbean superclass which does
Subject.login() based on e.g. OAuth headers or cook
One option could be Standard Servlet security offers Basic auth, SSL and
other goodies. Configure your web.xml pointing to an actionbean url
El mar 2, 2015 4:38 PM, "Joaquin Valdez"
escribió:
> Thanks Rick! Off topic a bit, but how are login credentials handled with
> this framework when callin
Thanks Rick! Off topic a bit, but how are login credentials handled with this
framework when calling a rest method?
Thanks
Joaquin
> On Feb 28, 2015, at 7:13 AM, Rick Grashel wrote:
>
> Hi guys,
>
> I also had similar issues writing REST services with Stripes. I absolutely
> did not w
Absolutely, there are many ways to implement pure HTTP backends with
Stripes. The verbs are not mandatory, you can stick to GET and POST it
works just fine. I never understood why everyone went that crazy with PUT
and DELETE. I think that Stripes shines at HTTP services implementation
(binding etc)
Hi guys,
I also had similar issues writing REST services with Stripes. I absolutely
did not want to get rid of Stripes, so I had to write a REST ActionBean
framework for Stripes which supported all of Stripes validation and
binding. If you are interested, you can download it here:
https://githu
We’ve just been lazy and done
public Resolution foo()
{
switch( getContext().getRequest().getMethod() )
{
case “post”:
return doPost();
case “get”
return doGet()
case “delete”:
return doDelete();
def
Hi,
we've been in the same situation, and we've used the same double approach
described by Remi: facing public, CMS-heavy sites using REST-like services
provided by Stripes, whereas transactional applications are invoking CMS's
services via its REST services.
The only downside with this approach
Btw, I've done something similar on a small app : we allow the site owner
to change some of the pages using MCE or something. We also allow to upload
images and reference them in those pages.
It does the job for us and for what it's cost, didn't take long to hack.
But it's pretty ugly, and we qui
Hi,
Interesting question :)
I guess a fundamental indicator is the complexity of the CMS vs your own
code. I mean, will the public facing website include only a small part of
customization (a few new forms here and there, a few pages...) and most of
the hits will be actually handled by the CMS ?
Hi,
We have been using Stripes for the last 5 years and love the framework. The
sites we have used it on are all transactional (think CRM) with back-end
integration to other systems for customer profile management, account
management etc.
We also have a fairly static public facing web site using w
12 matches
Mail list logo