Hi Craig,
> You can use request.isUserInRole() in your controller servlet as well (actually, it
>would be
> implemented inside an action class perform() method in the model we've been
>discussing) to let
> your business logic decide whether or not to execute something, or to vary the way a
>particular
> business function works (say, allow regular users to select records for the current
>department,
> but allow managers to select records for any department). This is one of the
>reasons I pass the
> HttpServletRequest along as an argument to my perform() method -- to make all the
>properties of
> the request available to the action class.
I understand, I'm not saying it cannot be done with isUserInRole(). But
in my architecture I don't
need to use isUserInRole() inside my business logic because the
"security framework" already
performed the appropriate security checks. So my perform() method just
does that: perform the
operation. I'm just trying to say that I find it much better when all
the checks are performed in
the security framework and the business logic just performs business
logic. IMHO, the security
framework of the JSDK2.2 is not able to do that because it forces you to
specify the security policy
(role/permissions requiered to perform an operation) STATICALLY.
> Alternatively (or in addition, they are not mutually exclusive), you could define
>URL patterns
> with security protection in the web.xml file so that a user could not even request a
>particular
> action URL (and therefore a piece of business logic you may or may not want them to
>use) unless
> they were in a specific role, and let the servlet container help you. For example,
>if the
> URL "/updatePayrollData.go" was the target of a form submit that only HR managers
>should
> execute, you could put a security mapping in web.xml protecting this specific URL,
>and not have
> to worry about it in your business logic.
Ok, let's try with an example:
We do have the operation "updateUserData" and we want the security roles
to be defined this way:
.- Users can modify their and only their informatio: So Pete can update
his only his data, Mary can
modify her and only her data and so on.
.- Managers can modify everybody's data: So ManagerJohn can update
everybody's data.
The name of the user whose data is being modified is provided with a
parameter passed to the
"updateUserData" operation.
So, how can you express this using JSDK2.2 security? AFAIK, unless you
mix security logic and
business logic in your perform() methods, you can't.
.- One possible solution would be to create a Role "ModifyUserX" for
every user that exists in the
users database, and grant it to every user, and all of them to the
manager. But you cannot do that
because the roles and permissions are specified STATICALLY in an XML
file, so changes in the
database wouldn't reflect in your security rules.
.- You would also need to set the requiered Role for the operation
"updateUserData" in runtime,
depending on the parameter that tells you whose data you are trying to
modify. This cannot be done
because the security protection (operations -> requiered Role) is also
specified STATICALLY in the
web.xml file. You migth try to play tricks with user's names and URL's
but this solution wouldn't
adapt well to changes in the users database so...
So we are back where we started, we would have to give users a general
role and then check inside
our business logic that the name of the authenticated user is the same
as the one whose data we are
trying to modify. Yes, I know, it can be done. I just think that if you
are doing something, try to
do it right. And IMHO a standard specification should be done right.
Just my 2c,
Dan
PD: On a side note, this is not an attack of any kind to the guys that
produced the specification
;). On the contrary, they have been quite open minded and interested in
feedbak. But they told me
they haven't got much feedback from this issue, which I find quite
interesting, so that's why I'm
trying to generate some. I think it's better to discuss things in
advance and do it almost right
from the beginning, than getting a final specification and start
complaining because it could have
done better.
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
