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
