Container-managed security also cannot deal with user roles, AFAIK. That is, if you have a user role and admin role (and possibly more) within your application, then you have to authenticate yourself so that you can determine the role.
My .02 cents on authentication: It is, IMHO, a very bad idea to authenticate in the JSP for secure applications, particularly when using Struts. The paradigm in Struts is that everything goes through Actions, and any secure JSP pages should not be directly accessible via URL mapping. If you authenticate only in these JSPs, an intruder could "sniff" out your Action URLs and wreak havoc by hitting them with requests full of garbage data, without being logged in. At the least, it will waste your Action classes' time by making them validate all of these unauthenticated, bogus requests that aren't caught because you are authenticating in JSP-land and not in Action-land. Authentication should always happen as early as possible in the request chain. Keeping this in mind, if you authenticate using a JSP tag, you are turning the Struts paradigm on its head: every request should go through a JSP first to authenticate, then redirect to an Action or another JSP. A more robust model is to keep all your JSPs hidden under WEB-INF, and use a ServletFilter attached to your ActionServlet to authenticate, or create an abstract Action base class which authenticates and then calls an abstract method implemented by a subclass if the user is logged in. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Monday, June 10, 2002 12:37 PM > To: Struts Users Mailing List > Subject: Re: User Authentication > > > > > > > > > > > > I've wondered why Struts provides no specific User Management tools. > I'd > > > almost expect to see a user.tld tag lib and struts tags such as: > > > > > Craig, > > Thanks for responding. I figured the answer was pretty much what you had > indicated. > > I also appreciate the exception cases you identified: > > > > > - You need self-registration capabilities (there's no mechanism > > in the Servlet API to support this yet) > > > - You need your app to run out of the box with no setup across > > multiple containers (this is the one and only reason that the > > Struts sample app uses self-registration, so people can use it > > to see if they have Struts installed correctly or not. > > So (for now at least) if I need to allow new users to sign up as part of > the app, I should have the app manage this. Or, If I want to be able to > deploy a .war file on a container somewhere without requiring the > "deployer" to configure the container, I should have the app manage > security itself. > > > To clarify - regarding self-registration. All I'd really need to build > would be just the registration pieces, wouldn't it? Once the users > registered, shouldn't the container manage their security the same as if I > created their accounts for them? > > > > Craig > > Thanks - > > Kevin > > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
