struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jae K" <invr...@gmail.com>
Subject Re: resume after login feature
Date Mon, 09 Apr 2007 01:17:31 GMT
Thanks Dave for that sanity check. The only difference between your
implementation and mine is that you put the originalUrl in a session whereas
I store it away in the client. They're both the same 'cleanlinest' i think.

Dale, I was considering ACEGI / SecurityFilter, but I still had to make sure
that this feature was *possible* before deciding to use Struts. If the
framework can't handle login-resume easily, then it can't be a good
framework. Fortunately everything works fine.

 - Jae

On 4/8/07, Dave Newton <newton.dave@yahoo.com> wrote:
>
> --- 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
>
>

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