Re: [Stripes-users] CMS Integration with Stripes

2015-03-03 Thread Janne Jalkanen

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 cookies or whatever you fancy.  
We use something like this:

@Before(stages=LifecycleStage.BindingAndValidation)
public void resolveAccessToken()
{
String bearer = getContext().getRequest().getHeader( "Authorization" );
String at = getContext().getRequest().getParameter("access_token");

if( bearer != null )
{
at = bearer.substring( AUTH_BEARER.length() ).trim();
}

/* some validation omitted due to brevity */

if( at != null )
{
try
{
AccessToken token = new AccessToken(at);

SecurityUtils.getSubject().login( token );
}
catch( Exception e )
{
/* some code here */
}
}
}

/Janne

On 3 Mar 2015, at 00:35, Nestor Hernandez  wrote:

> 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 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 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://github.com/rgrashel/stripes-rest
>> 
>> I can help anybody out with implementation of a REST service if they need 
>> it.  But for this library, full Stripes validation is supported.  It uses 
>> the same "convention" approach that Stripes uses, so you write get(), 
>> post(), delete(), head(), put() methods and they will be automatically 
>> called.  It also uses Stripes' own internal Javascript builder and has a new 
>> JsonResolution to create JSON-based responses.
>> 
>> Give it a look if you are interested.  I have been using it in production 
>> for quite awhile and it works well.
>> 
>> Thanks.
>> 
>> -- Rick
>> 
>> 
>> On Sat, Feb 28, 2015 at 7:17 AM, Janne Jalkanen  
>> wrote:
>> 
>> 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();
>>   default:
>>  return new ErrorResolution( … );
>>  }
>> }
>> 
>> What’s a bit more difficult is to incorporate validation into this, but we 
>> basically have a superclass which has something like this:
>> 
>> /**
>>  *  Normally Stripes turns validation errors into HTML, but since this 
>> is an API,
>>  *  we turn it into JSON.  Returns a JSON resolution with a single
>>  *  field "error" which then contains a number of errors.
>>  */
>> @Override
>> public Resolution handleValidationErrors( ValidationErrors errors )
>> {
>> JSONObject obj = new JSONObject();
>> 
>> obj.put( "error", constructErrorObject(errors) );
>> 
>> return new JSONResolution( HttpServletResponse.SC_BAD_REQUEST, obj );
>> }
>> 
>> /**
>>  *  Turns a ValidationErrors document into JSON.
>>  *
>>  *  @param errors
>>  *  @return
>>  */
>> private Object constructErrorObject( ValidationErrors errors )
>> {
>> JSONObject obj = new JSONObject();
>> 
>> if( !errors.hasFieldErrors() )
>> {
>> if( errors.containsKey( ValidationErrors.GLOBAL_ERROR ) )
>> {
>> obj.put( "code", ERR_VALIDATION );
>> obj.put( "description", errors.get( 
>> ValidationErrors.GLOBAL_ERROR ).get( 0 ).getMessage( 
>> getContext().getLocale() ) );
>> }
>> }
>> else
>> {
>> for( List list : errors.values() )
>> {
>> obj.put( "code", ERR_VALIDATION );
>> obj.put( "description", list.get(0).getFieldName() + ": "+ 
>> list.get( 0 ).getMessage( getContext().getLocale() ) );
>> }
>> }
>> 
>> obj.put("status", 400);
>> 
>> return obj;
>> }
>> 
>> JSONResolution is a custom class which has this in its heart:
>> 
>> protected static ObjectMapper c_mapper = new ObjectMapper();
>> protected static ObjectMapper c_prettyMapper = new ObjectMapper();
>> 

Re: [Stripes-users] CMS Integration with Stripes

2015-03-03 Thread Rick Grashel
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
AuthenticateRestActionBean which performs a custom token-based
authentication.  Folks could do authentication using their own interceptor,
a filter, JAAS or whatever they want.

-- Rick



On Mon, Mar 2, 2015 at 3:36 PM, Joaquin Valdez 
wrote:

> 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 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://github.com/rgrashel/stripes-rest
>
> I can help anybody out with implementation of a REST service if they need
> it.  But for this library, full Stripes validation is supported.  It uses
> the same "convention" approach that Stripes uses, so you write get(),
> post(), delete(), head(), put() methods and they will be automatically
> called.  It also uses Stripes' own internal Javascript builder and has a
> new JsonResolution to create JSON-based responses.
>
> Give it a look if you are interested.  I have been using it in production
> for quite awhile and it works well.
>
> Thanks.
>
> -- Rick
>
>
> On Sat, Feb 28, 2015 at 7:17 AM, Janne Jalkanen 
> wrote:
>
>>
>> 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();
>>   default:
>> return new ErrorResolution( … );
>> }
>> }
>>
>> What’s a bit more difficult is to incorporate validation into this, but
>> we basically have a superclass which has something like this:
>>
>> /**
>>  *  Normally Stripes turns validation errors into HTML, but since
>> this is an API,
>>  *  we turn it into JSON.  Returns a JSON resolution with a single
>>  *  field "error" which then contains a number of errors.
>>  */
>> @Override
>> public Resolution handleValidationErrors( ValidationErrors errors )
>> {
>> JSONObject obj = new JSONObject();
>>
>>
>> obj.put( "error", constructErrorObject(errors) );
>>
>>
>> return new JSONResolution( HttpServletResponse.SC_BAD_REQUEST,
>> obj );
>> }
>>
>> /**
>>  *  Turns a ValidationErrors document into JSON.
>>  *
>>  *  @param errors
>>  *  @return
>>  */
>> private Object constructErrorObject( ValidationErrors errors )
>> {
>> JSONObject obj = new JSONObject();
>>
>>
>> if( !errors.hasFieldErrors() )
>> {
>> if( errors.containsKey( ValidationErrors.GLOBAL_ERROR ) )
>> {
>> obj.put( "code", ERR_VALIDATION );
>> obj.put( "description", errors.get( ValidationErrors.
>> GLOBAL_ERROR ).get( 0 ).getMessage( getContext().getLocale() ) );
>> }
>> }
>> else
>> {
>> for( List list : errors.values() )
>> {
>> obj.put( "code", ERR_VALIDATION );
>> obj.put( "description", list.get(0).getFieldName() + ": "+
>> list.get( 0 ).getMessage( getContext().getLocale() ) );
>> }
>> }
>>
>>
>> obj.put("status", 400);
>>
>>
>> return obj;
>> }
>>
>> JSONResolution is a custom class which has this in its heart:
>>
>> protected static ObjectMapper c_mapper = new ObjectMapper();
>> protected static ObjectMapper c_prettyMapper = new ObjectMapper();
>>
>>
>> static
>> {
>> c_prettyMapper.configure( SerializationFeature.INDENT_OUTPUT,
>> true );
>> }
>>
>> @Override
>> public void execute( HttpServletRequest request, HttpServletResponse
>> response ) throws Exception
>> {
>> response.setStatus( m_status );
>> response.setContentType( m_contentType );
>> response.setCharacterEncoding( "UTF-8" );
>>
>>
>> if( "true".equals(request.getParameter( "pretty" )) )
>> c_prettyMapper.writeValue( response.getOutputStream(),
>> m_object );
>> else
>> c_mapper.writeValue( response.getOutputStream(), m_object );
>>
>> response.getOutputStream().flush();
>> }
>>
>> This btw lets you just get nice JSON back from any API call by adding
>> “&pretty=true” to the request URL.  This has proven to be invaluable while
>> debugging.
>>
>> One important caveat is that to protect against CSRF attacks you will
>> want to make sure that every singl