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> 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
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