Great gist my friend! I was wondering about another alternative more simple. Currently AeroGear security implements HttpStatusAwareException (I'll rename to HttpStatusAware and qmx is responsible for the hipster name) public class AeroGearSecurityMeh implements HttpStatusAware { @Override public int getStatus() { //something here } @Override public String getMessage() { //something here } } Then in AeroGearSecurityProvider we could change the method return and do something like this: public class AeroGearSecurityProvider implements SecurityProvider { @Inject private AeroGearPrincipal principal; @Override public AeroGearSecurityMeh isRouteAllowed(Route route) throws ServletException { if (!principal.hasRoles(route.getRoles())) { return new AeroGearSecurityMeh(1, "Geez, authentication has failed"); } } } Wdyt? Makes sense? -- "The measure of a man is what he does with power" - Plato - @abstractj - Volenti Nihil Difficile On Thursday, November 1, 2012 at 6:14 AM, Daniel Bevenius wrote: Hi, I'm working on AEROGEAR-581 and have put together some background information and some prototype code in this gist: https://gist.github.com/3992369 If you read the conclusion section you'll see that I'm not convinced that CDI events are a good fit in this specific situation, but I'd be happy to learn otherwise :) Thanks, /Dan _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

I've pushed a suggestion and tried to explain it here: https://gist.github.com/4001775 Let me know what you think. Thanks, On 2 November 2012 08:45, Daniel Bevenius <daniel.bevenius(a)gmail.com (mailto:daniel.bevenius@gmail.com)> wrote: > That makes sense for sure. How about a SecurityDecision or > SecurityResult class that a SecurityProvider can return. > > public class SecurityDecision { > public boolean allowed() { > return allowed; > } > > public Response response() { > return response; > } > > } > Response would contain the statusCode and statusMessage to be returned > to the caller. > > > On 2 November 2012 07:58, Bruno Oliveira <bruno(a)abstractj.org (mailto:bruno@abstractj.org)> wrote: > > Great gist my friend! I was wondering about another alternative more simple. > > Currently AeroGear security implements HttpStatusAwareException (I'll rename > > to HttpStatusAware and qmx is responsible for the hipster name) > > > > public class AeroGearSecurityMeh implements HttpStatusAware { > > > > @Override > > public int getStatus() { > > //something here > > } > > > > @Override > > public String getMessage() { > > //something here > > } > > } > > > > Then in AeroGearSecurityProvider we could change the method return and do > > something like this: > > > > public class AeroGearSecurityProvider implements SecurityProvider { > > > > @Inject > > private AeroGearPrincipal principal; > > > > @Override > > public AeroGearSecurityMeh isRouteAllowed(Route route) throws > > ServletException { > > > > if (!principal.hasRoles(route.getRoles())) { > > return new AeroGearSecurityMeh(1, "Geez, authentication has > > failed"); > > } > > } > > } > > > > Wdyt? Makes sense? > > > > -- > > "The measure of a man is what he does with power" - Plato > > - > > @abstractj > > - > > Volenti Nihil Difficile > > > > On Thursday, November 1, 2012 at 6:14 AM, Daniel Bevenius wrote: > > > > Hi, > > > > I'm working on AEROGEAR-581 and have put together some background > > information and some prototype code in this gist: > > https://gist.github.com/3992369 > > > > If you read the conclusion section you'll see that I'm not convinced > > that CDI events are a good fit in this specific situation, but I'd be > > happy to learn otherwise :) > > > > Thanks, > > > > /Dan > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev(a)lists.jboss.org (mailto:aerogear-dev@lists.jboss.org) > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev(a)lists.jboss.org (mailto:aerogear-dev@lists.jboss.org) > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org (mailto:aerogear-dev@lists.jboss.org) https://lists.jboss.org/mailman/listinfo/aerogear-dev