> Hmm, I wonder what kind of overhead that incurs. Of course, if you are 
> only checking it once per HTTP request, I don't suppose it would matter. 
> Sounds like it would be roughly equivalent to creating an exception (due 
> to the stack trace manipulation).

You are totally right ;). At the beginning I've added this check to many
methods (which is not necessary at all) and because the generation of the
StackTrace is a very expensive operation, some pages needed long time to get
generated (about 1-2 seconds) (The check method was called more than a few
thousand times).

I've ended up in just adding the annotations to methods, which did not get
called thousand times per request ;). Mostly I am checking the access rights
via the annotations on bean creation (e.g.: It does not make sense to allow
a customer to instantiate an administration bean).

But you can easily pass the current method as parameter to the check method,
so no stack trace has to be generated, which is solving the performance
problem anyway.

> Andrew is doing something like this too. Maybe if they come out with new 
> versions of the java security frameworks, they can standardize on this 
> sort of thing. :)

Yeah ;)...

Dominik


-----Ursprüngliche Nachricht-----
Von: Jeff Bischoff [mailto:[EMAIL PROTECTED] 
Gesendet: Dienstag, 7. November 2006 19:38
An: MyFaces Discussion
Betreff: Re: AW: AW: AW: [O/T] JSF Best Practices for
Authentication/Authorization

Dominik,

Hmm, I wonder what kind of overhead that incurs. Of course, if you are 
only checking it once per HTTP request, I don't suppose it would matter. 
Sounds like it would be roughly equivalent to creating an exception (due 
to the stack trace manipulation).

Andrew is doing something like this too. Maybe if they come out with new
versions of the java security frameworks, they can standardize on this sort
of thing. :)

Regards,

Jeff Bischoff
Kenneth L Kurz & Associates, Inc.

[EMAIL PROTECTED] wrote:
> Yes, that's correct, the JsfSecurityManager get's the stack trace, looks
up
> the calling method, retrieving the annotation, checking the access rights,
> and throwing an exception if access is not allowed.
> 
> 
>  > @SecurityGuard(TypRoles.ADMIN)
>  > public AdminBean getAdminBean()
>  > {
>  >    JsfSecurityManager.getCurrentInstance().check();
>  > }
>  >
> 
> Like I said, we haven't moved to the new Java yet. But okay, so the 
> annotation is labeling that this method should only be run by admins, 
> and it's the SecurityManager that is responsible for looking at the 
> annotation and deciding whether to continue?
> 
> 
> 
> 
> 


Reply via email to