struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Page <>
Subject RE: best practices for logging in
Date Mon, 25 Feb 2002 16:39:44 GMT
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

> -----Original Message-----
> From: Bryan Field-Elliot []
> 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:   
> <>
>     For additional commands, e-mail: 
> <>

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message