Mailing-List: contact user-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Users Mailing List" <user@struts.apache.org>
Received-SPF: pass (herse.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID;
  b=AnccS52ev7cATncd5A9bb32si08aIho/eNN7OpdwGvTBV7XS6qXNUPL9uHggOS6wgfuTq9uNdAYetXBGL4MILLmcx8gWwf8MNDb9rpDh3N971ZpFJ4twn6aIuKJNzBecwOGncoJjUHhhfe+35obpdwuekd9lwfxW/RDWt8MABUY=;
Date: Sun, 8 Apr 2007 16:26:37 -0700 (PDT)
From: Dave Newton <newton.dave@yahoo.com>
Subject: Re: resume after login feature
To: Struts Users Mailing List <user@struts.apache.org>
In-Reply-To: <4649a9a20704081402n29b68813wfb7664598b6706f5@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Message-ID: <414422.94896.qm@web56714.mail.re3.yahoo.com>

--- Jae K <invrnrv@gmail.com> wrote:
> Of course in Login.jsp you need...
> <s:form action="Login.do" validate="true">
>   <s:if test="${param.origurl ne null}">
>     <s:hidden name="origurl" 
>               value="${param.origurl}"/>
>   </s:if>
> ....
> 
> And finally, this has the side effect that all
> links on the login page created with <s:url ...> 
> will also have the origurl parameter. You can 
> override this behavior by setting 
> includeParams="none" (i think), but it's not 
> strictly necessary because the <s:form ...> 
> action does not inherit those parameters.

I *still* believe you are making this weirder than it
needs to be and that earlier advice given would lead
to a better solution (or you could use Acegi as
suggested--I found it very irritating at first,
though!)

As a proof of concept, I did (more or less) the
following, just as a sanity check:

- IRolesAware

Actions requiring login implement this (contains
get/setRoles) and are given a "roles" <param.../> in
their struts config. Not a perfect solution, but for
demonstration purposes it's fine.

- RolesInterceptor

If the invoked action impls IRolesAware it checks for
login, if not logged in it puts the requested URL
(with query string) into session and returns the login
page's global result.

- LoginAction

If login succeeds puts the original url from session
into a property originalUrl and returns a SUCCESS
result, which is a result for LoginAction that looks
like:

<result type="redirect">${originalUrl}</result>

...also set loggedIn indicator and removes
originalUrl.

So there is nothing special going on; you check for a
login in the interceptor (and can check for specific
roles against the roles the action expects, but that's
not really part of the discussion). Not logged in,
save URL and go to login. (Optionally if not right
role, go to wherever you need to based on whatever
criteria you want.) Logged in and/or have the role,
process the invocation normally.

It just seems cleaner; what am I missing?

d.


____________________________________________________________________________________
TV dinner still cooling? 
Check out "Tonight's Picks" on Yahoo! TV.
http://tv.yahoo.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org