Daniel Lopez wrote:
> Hi Craig,
>
> Comments intermixed,
>
> <snip, snip, snip...>
>
> > > It might be that I haven't really understood how security is specified in
>JSDK2.2 but
> > > how would you solve the case of having two diferent users(with different
>privileges)
> > > accessing two different sets of data(which require different roles) using the
>same
> > > servlet/JSP(which means the same URL with different request parameters)? A basic
> > > example, several users accesing their own preferences for an application. You
>don't want
> > > one user to see the preferences of another user and you don't want to create a
>diferent
> > > JSP for each user. Given the JSDK2.2 spec, the only solution I can think of, is
>using
> > > "isUserInRole()" inside the JSP or the servlet to check whether the parameters
>match the
> > > authenticated user, so we are back again to mixing security and business logic.
>Am I
> > > missing something?
> > >
> >
> > That's exactly what isUserInRole() is for -- to let you vary the response based on
>the
> > security permissions of the current user. So, to show a chunk of your JSP page
>only to
> > managers, you would do something like this:
> >
> > <% if (request.isUserInRole("manager")) { %>
> > ... the output that only managers should see ...
> > <% } %>
> >
> > To me, this counts as "presentation logic" rather than "business logic", because
>nothing in
> > the underlying business model (in your beans) is affected. However, if you don't
>like
> > scriptlets embedded in your JSP pages, you can also write a custom tag to
>accomplish this
> > -- perhaps it would end up looking like:
> >
> > <mytags:rolecheck role="manager">
> > ... the output that only managers should see ...
> > </mytags:rolecheck>
>
> Well, I was talking more about "getting the whole information", not
> about "showing a piece in the UI". I mean, I don't want my business
> logic to perform the query and retrieve the information, forward the
> control to the JSP and then use isUserInRole() to detect that I
> shouldn't show him the information. I don't want to perform the query in
> the first place. And what about deleting some information? You would
> have to perform isUserInRole() checks inside your business logic to see
> if he's the rigth guy before performing the operation. And then we are
> back almost in the place where we started, performing security checks in
> the business logic. I'm not trying to say that introducing security in
> the JSDK is not an inprovement and that it doesn't help. I'm just trying
> to say it could be done much better and that I don't find it flexible
> enough, IMHO.
>
How about using the declarative security in web.xml to protect the specific URL(s)
that invoke
the business logic you want to protect? That way you don't have to code it in any JSP
page, any
servlet, any business logic, or anywhere else ... except the security constraint in
web.xml.
This seems to meet your objective of not executing things you don't want users to
access unless
they are authorized.
In a Model 2 environment, you'd be putting security constraints around the URL that
invoked the
business logic itself (using whatever approach you've defined for picking the URL
format for
this). For completeness, you might want to also protect the corresponding display
URLs (i.e.
the ones that invoke the JSP pages you'd be forwarding to if the business logic
actually ran),
but that's not strictly necessary.
>
> > > And, if I'm not mistaken, you'll have to redeploy the security part of your
>application
> > > every time you change from one container to another. And that's something you
>didn't
> > > have to do before.
> >
> > In the sense that every container has their own implementation, you're correct ...
>you are
> > going to need to code it differently for each platform, because the interface
>between
> > platform and security realm is not standardized (progress in that direction would
>be good
> > IMHO). However, it's still a good tradeoff in terms of overall development
>effort, versus
> > all the stuff you have to build in to a servlet/JSP app to do it all yourself.
>
> I agree with you that progress in that direction would be a good effort,
> because having to recode the security interface every time you want to
> change/test a different container could be a real pain. It would be
> ironic to have a completely portable, platform neutral, container
> independent WAR application where you can read in tiny font "except the
> security mappings that have to be redeployed for every container" ;).
>
I would tend to expect some focus on standardizing this area in the spec. But the way
it is
still beats the heck out of doing it all yourself, IMHO :-).
>
> > Craig
>
> Dan
>
Craig
===========================================================================
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
