[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ajug-members]: User authentication in web app
That's great. Thanks much.
On Tue, 2004-03-16 at 13:12, Rob Kischuk wrote:
> You mention checking the authorization of the user at 2 levels - the
> presentation tier, to give the user a clean view of what they can do,
> and the back end, to ensure they don't do things they shouldn't be able
> to do. The first thing to understand is that J2EE security readily
> supports the association of users and roles, and this information is
> kept as part of the user's session.
>
> For keeping your view clean, the most direct way to check authorization
> is with HttpServletRequest.isUserInRole( String ) - which returns true
> if the user is in the requested role, otherwise false. By embedding the
> code you want show inside an if statement:
>
> <% if (req.isUserInRole("admin")) { %>
> <show stuff>
> <%}%>
>
> you can ensure that the content is shown only to those who are
> authorized to see it. For those who don't like scriptlets in their JSP,
> the request taglib from the jakarta taglibs project
> (http://jakarta.apache.org/taglibs/index.html) has a simple tag that
> fits the bill:
>
> <req:isUserInRole role="admin">
> <show stuff>
> </req:isUserInRole>
>
> For securing your app on the back end, you have a couple of options. If
> your security can be described in patterns (like if all admin
> functionality is under the /admin/ path, or admin.so is a struts action
> that handles admin functionality), you can declaratively specify the
> secured resources and allowed roles in your web.xml, and the container
> will ensure that only authorized users access those resources. If,
> however, you have something that is not easily described with a pattern
> (such as a struts dispatch action), you can also use
> request.isUserInRole() in your servlet or struts action - if a user
> isn't authorized, redirect them to the 403/Forbidden error (or whatever
> action you want to take). Struts can apparently also handle some
> security with role-based authorization, but I've never really messed
> with it.
>
> You could conceivably write a struts action to show different pages
> based on the user, but I've found that many situations are best solved
> by using the same page, selectively omitting items that the user isn't
> authorized to see.
>
> -Rob
>
> Scott P. Smith wrote:
>
> >Rob & Chandra,
> >
> >That's great information. Thanks.
> >
> >At my last job, we had pages where different parts of the page had
> >different permissions associated with them. So two different people
> >with different roles would see different options on the page. Some
> >roles could just view certain data while other roles could edit. We
> >chose to use entirely custom logon/authentication with our own custom
> >tag library that would hide or show portions of the page based on the
> >user's role. Of course, the back end (we used struts) would also check
> >the user's permissions against the action he was trying to perform.
> >
> >Can container managed security handle this kind of sub-page level access
> >control?
> >
> >I can image that struts could display a different page, based on the
> >user's role, but I don't think it could do that back when I was using it
> >(3 years ago).
> >
> >I have never used container managed security so I'm picking your brains,
> >while I have the chance.
> >
> >Thanks,
> >
> >Scott
> >
> >
>
>