[aerogear-dev] [aerogear-controller] Handling SecurityProvider Exceptions/Events

[Bruno Oliveira]

Hi my friend! First at all, great gist! And answering your question:

* Should it really be AeroGear-Controller that determines if a response should be returned to the caller, or if it should forward to a view?

IMO it should be forward to a view.

Few comments about that gist. If we bring SecurityResult to aerogear-controller we're bringing concepts which do not belong to aerogear-controller, concepts like unauthorized, forbidden and etc, that is my concern.

My suggestion is a little bit simple https://gist.github.com/c635dc2e5e82ba666ca3, the provider chooses how to implement that and uses http status responses by convention.

Wdyt? Makes sense?

-- 
"The measure of a man is what he does with power" - Plato
-
@abstractj
-
Volenti Nihil Difficile



On Friday, November 2, 2012 at 12:54 PM, Daniel Bevenius wrote:

> 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 at gmail.com (mailto:daniel.bevenius at 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 at abstractj.org (mailto:bruno at 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 at lists.jboss.org (mailto:aerogear-dev at lists.jboss.org)
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev at lists.jboss.org (mailto:aerogear-dev at lists.jboss.org)
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > 
> 
> 
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org (mailto:aerogear-dev at lists.jboss.org)
> https://lists.jboss.org/mailman/listinfo/aerogear-dev