struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kiss, Tibor (Contractor)" <>
Subject AW: AW: Best way to accomplish interstitial logins?
Date Thu, 23 Jan 2003 18:16:08 GMT
And your filter should intercept unathorized access, forward to a login
page, authorize/register the user, and then redirect him, to the page he was

I did not use Struts for the login/register thing, it is completely handled
by the filter.


-----Urspr√ľngliche Nachricht-----
Von: David Graham []
Gesendet: Donnerstag, 23. Januar 2003 19:06
Betreff: Re: AW: Best way to accomplish interstitial logins?

I put pages that required a login under the /secure directory and mapped 
/secure/* to an authentication filter.


>From: "Kiss, Tibor (Contractor)" <>
>Reply-To: "Struts Users Mailing List" <>
>To: "'Struts Users Mailing List'" <>
>Subject: AW: Best way to accomplish interstitial logins?
>Date: Thu, 23 Jan 2003 18:56:54 +0100
>Have you tried using a filter for Authentication and Authorization?
>I had the same requirement, and implemented it via a filter.
>-----Urspr√ľngliche Nachricht-----
>Von: Jeff []
>Gesendet: Donnerstag, 23. Januar 2003 18:55
>Betreff: Best way to accomplish interstitial logins?
>Is there a way to accomplish interstitial user logins using Struts that
>doesn't seem to defeat part of the reason for using Struts in the first
>By "interstitial", I mean situations where users arrive on the site and can
>roam & act freely UNTIL they try to do something that requires a valid
>login. At that point, they'd be shown a login screen, cycled through it a
>few times if they enter an invalid username or password, then continue with
>their original request as though nothing had happened to interrupt it.
>Ideally, even new user registration could take place as an interstitial
>For a concrete example, suppose a user visits a career site. He browses 
>for a while, then finds one that looks interesting and clicks "apply
>online". At that point, the Action-extending class realizes that he needs 
>be logged in to continue, so it takes a sidetrip to log him in, or register
>him as a new user, before transparently finishing the original activity as
>though the interruption in the middle (to login or register) had never
>I've implemented something like that in the past using Struts 1.0, but 
>up feeling like I was trying to hammer a square peg into a round hole.
>Basically, I created an abstract FormBean that encapsulated the username,
>password, and submit button, then used it as the superclass of every other
>FormBean used by the application. The general idea being that every form
>then became a potential login form, with the login elements normally not
>displayed, but ONLY the login elements displayed at interstial login time.
>actions that didn't require that the user be authenticated were mapped to
>classes that extended the Struts Action class. Actions that DID require
>authentication extended the AuthenticatedUserAction class, and their
>perform(*) method checked to make sure the user was logged in. If not, it
>tried to log in the user (if a username and password were submitted with 
>last form submission) and returned the actionmapping to the login page if
>the user couldn't be logged in. If yes, it returned the result of
>performLoggedInUserAction(*), which served the same purpose as perform(*) 
>unprotected pages.
>The brick wall came from the requirement that Struts forms specify a
>*compile-time* value for the form's action. Since the request that resulted
>in the login form's display could have been to just about ANY plausible
>mapped path in the webapp, and ultimately the form had to submit to that
>exact same action in order to transparently complete the action, there
>seemed to be only two work-arounds:
>* create a login page for every single mapped Action in the site. Ouch.
>* do everything through one ungodly huge monolithic Action
>Creating dozens of login pages that were identical except their action
>parameter was a pain, but doing everything through a single monolithic
>action seemed even worse architecturally, because it seemed to defeat the
>purpose of mapping actions to forwards in struts-config.xml instead of
>hardcoding them in the controller.
>At the time, I took advantage of Struts' open-source nature to create a
>Third alternative: I hacked Struts to permit struts forms with null action
>parameters. At launch time, it stored the action to which the form was
>submitted in request context. A few milliseconds later, when the form was
>being rendered, if the rendering class discovered that the form's action 
>null, it would silently retrieve the action from request context and  "fill
>in the blank", so to speak. It worked, but it kind of bothered me that
>Struts' designers probably had a good reason for not allowing that 
>since hacking the appropriate classes to allow it took all of maybe an hour
>and seemed like too easy of a solution to not have some Good Reason for its
>So... what's the Right Way to implement interstitial logins? Is there
>possibly some new feature that came out with 1.1 that solves this problem?

Protect your PC - get VirusScan Online

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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message