struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kiss, Tibor (Contractor)" <Tibor.K...@upc.at>
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
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:dgraham1980@hotmail.com]
Gesendet: Donnerstag, 23. Januar 2003 19:06
An: struts-user@jakarta.apache.org
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)" <Tibor.Kiss@upc.at>
>Reply-To: "Struts Users Mailing List" <struts-user@jakarta.apache.org>
>To: "'Struts Users Mailing List'" <struts-user@jakarta.apache.org>
>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:lists@skubick.com]
>Gesendet: Donnerstag, 23. Januar 2003 18:55
>An: struts-user@jakarta.apache.org
>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:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail:
<mailto:struts-user-help@jakarta.apache.org>

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