No, no! The authentication agent takes care of role maintenance. When, for
example, a login is made on Orion, the UserManager sets the available groups
(i.e., roles) on that user; it doesn't do it on every page request, and does
it sans developer interaction at that point. Same benefit, less work. Less
work sounds good to me. As far as "isUserInRole..." well, yeah, that's fine;
semantics. What's actually happening there is that you're calling the
servlet context to find out about the current user (i.e., see
HttpServletRequest.getUserPrincipal(), et al.) There's still no need from an
authentication standpoint (again, in most cases!) to rely on
application-level implementation.
>From: Tom Preston <[EMAIL PROTECTED]>
>Ok. So let's call it a role instead of a priv (a role being a set of
>privs). Somehow the work to tie the user making a webserver request to a
>role has to be done in order for the javabean to return its boolean
>response:
><utils:ifInRole name="managers">
> <a href="managerlink/">
> ManagerLink
> </a>
></utils:ifInRole>
>
>The javabean might as well be called "ifUserInRole". So, the question is
>how are you authenticating universally that the user is in the role. You
>can go to the DB every time that you see this bean, but you pay to do that
>if the whole site is role based, or you can store the roles (as very small
>strings) in the servlet session.
>
>
>>From: Joseph Ottinger <[EMAIL PROTECTED]>
>>Reply-To: A mailing list about Java Server Pages specification and
>> reference <[EMAIL PROTECTED]>
>>To: [EMAIL PROTECTED]
>>Subject: Re: Check security for userID & password
>>Date: Thu, 22 Feb 2001 10:34:03 -0500
>>
>>I still disagree, and here's why: privileges should be assigned to roles,
>>not specific users. I don't know of a web server that doesn't support the
>>concept of a role; the idea is "don't expose this section of the web site
>>to
>>people who aren't in this role," which means that the authentication
>>mechanism STILL takes care of it. If you're trying to not even expose a
>>link
>>to a protected resource, it gets a TAD more complicated, but not by much:
>>you'd wrap the links in an if, based on role validation. In tag parlance:
>>
>><utils:ifInRole name="managers">
>> <a href="managerlink/">
>> ManagerLink
>> </a>
>></utils:ifInRole>
>>
>>Using scriptlets wouldn't be much different. This way, the container is
>>still maintaining this information, and your app doesn't have to know
>>about
>>it - to me, this is STILL a more elegant solution.
>>
>>I don't mean that you simply cannot win the "JBO Seal of Approval" (a very
>>valuable award - it, plus three quarters, will buy you a cup of coffee and
>>a
>>lot of strange looks in most places) if you store user information in a
>>session - but that you don't have to store user information in sessions to
>>achieve what you're talking about. And you're also correct in that it's
>>not
>>always black and white - but it is for most cases. (If you're in one of
>>the
>>myriad cases where it's NOT black and white, then you generally know what
>>to
>>do about it anyway.)
>>
>>
>>>From: Tom Preston <[EMAIL PROTECTED]>
>>>Reply-To: A mailing list about Java Server Pages specification and
>>> reference <[EMAIL PROTECTED]>
>>>To: [EMAIL PROTECTED]
>>>Subject: Re: Check security for userID & password
>>>Date: Thu, 22 Feb 2001 15:20:45 -0000
>>>
>>>There are cases where you may need to store some info about the user's
>>>authentication or privilege information in a session. Saying "don't ever
>>>put authentication information in a session" is wrong. You may have a
>>>set
>>>of private pages (or sites) that should only be seen by a certain set of
>>>users. It is not unacceptable on user login to store some info about
>>>this
>>>user's privs in the session....that way you don't continually go back to
>>>the
>>>db to check if it is ok for the user to see this page. You prob don't
>>>want
>>>to store the username/password in the session, but storing the users
>>>privs
>>>in memory is not necessarily bad....these auth questions often have to do
>>>with number of sites/pages that you support, different sets of users that
>>>you support, and total number of users that you support. This is not so
>>>black and white.
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST".
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
