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 before.
I did not use Struts for the login/register thing, it is completely handled by the filter. tibor -----Urspr�ngliche Nachricht----- Von: David Graham [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 23. Januar 2003 19:06 An: [EMAIL PROTECTED] 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. David >From: "Kiss, Tibor (Contractor)" <[EMAIL PROTECTED]> >Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]> >To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]> >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 [mailto:[EMAIL PROTECTED]] >Gesendet: Donnerstag, 23. Januar 2003 18:55 >An: [EMAIL PROTECTED] >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 >place? > >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 >activity. > >For a concrete example, suppose a user visits a career site. He browses >jobs >for a while, then finds one that looks interesting and clicks "apply >online". At that point, the Action-extending class realizes that he needs >to >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 >happened. > >I've implemented something like that in the past using Struts 1.0, but >ended >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 >the >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(*) >in >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 >was >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 >practice, >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 >absence. > >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 McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
