12:04 p.m.
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(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