I use a variant on 2. I have my own action, but I don't use an unimplemented method (which I wouldn't do in this case anyway, would implement it with a default, probably not requiring login , that would depend on the project). Instead I use the parameter in the config to do this (my config parameters are set up to allow multiple values using a key1=value1;key2=value2 syntax). My action class also forward using a global forward named needslogin (orsomething like that).That way you can simply change the config file if you want to tighten or loosen the login requirements. Obviously some actions will require a login because of database access, but those that don't can come and go as your customer wants.
> -----Original Message----- > From: Bryan Field-Elliot [mailto:[EMAIL PROTECTED]] > Sent: Sunday, February 24, 2002 11:20 AM > To: Edward Q. Bridges > Cc: Struts Users Mailing List > Subject: Re: best practices for logging in > > > You want to set a session-level boolean value (actually Boolean, not > boolean, since you can only store proper objects in the > session scope), > indicating whether the user has logged in. > > Here are three ways to build a framework with Struts to check for > "logged-inness". I've used all three in succession, and my preference > nowadays is the last method. > > 1. At the start of each of your Action's perform() methods, have a > common block of code to check for logged-inness, and redirect > to a login > page as appropriate. Primary disadvantage is that you have to remember > to cut and paste this code into all your actions which > require a login. > > 2. Extend Struts' Action class to your own *abstract* class, > which adds > the (unimplemented method) "boolean requiresLogon()". All of your > actions should extend this abstract class, and implement their own > "requiresLogon()" method which simply returns true or false. Then, in > the base class's perform() method, you can call > requiresLogon(), and if > true, then test for logged-inness. Lastly, you can call the derived > class's real "perform" method, which actually you'll have to > rename to, > "myPerform" or something slightly different. This is a > cleaner approach > than #1 but still a bit messy. I've used this approach for both > "requiresLogon()", and "requiresDatabase()" (in which case I establish > and break down a connection, all in one place). My preference > is now #3, > below. > > 3. Don't use Struts at all for your login check. Instead, use Servlet > Filters (requires a Servlet 2.3 container such as Tomcat > 4.0). Implement > a filter (they're simple, really!) which checks for logged-inness, and > if false, then redirects to some login page. This has a clear > advantage > in that it separates security checking from the code of your > Actions. In > addition, it has a clear advantage in that it's declarative at the > configuration file (XML) level, rather than embedded in your code. By > that I mean, in the web.xml file, you specify which URL's (or which > patterns of URL's) the filter applies to, rather than > embedding this in > your actual Java code. My favorite approach to this kind of thing. > > Some other notes: > > 1. If the login check fails, you can do your user a favor by > saving the > URL they requested into a session variable. Then, in your logon code, > upon successful login, you can redirect the user back to the URL they > originally requested. A nice convenience. > > 2. "logged-inness" is a perfectly legitimate and grammatically correct > expression. > > Bryan > > > On Sun, 2002-02-24 at 08:46, Edward Q. Bridges wrote: > > what is the general "accepted practice" for handling > logins and securing > access with struts? > > from a review of the archive, it seems that way *not* to > do it is to use a > "isLoggedIn" flag that gets passed from page to page. > and, that the > canonical approach is to utilize Action.perform(...) to > determine whether > or not the person has logged in. > > so, how exactly is the Action class determining whether > or not the user is > "logged in"? does it set a session-level boolean > variable and check that > on every invocation of the perform method? > > has anyone encountered special cases where they've had to > come up with some > unique way of handling logins? > > many thanks! > --e-- > > > > -- > 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]>
