struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Benedict" <pbened...@apache.org>
Subject Re: Login implementation, how to forward user to original destination?
Date Mon, 01 Oct 2007 12:49:22 GMT
There's no perfect solution. You should choose a first-win or last-win
strategy.

Paul

On 10/1/07, Anton Pussep <anton-ml@pussep.de> wrote:
>
> First of all thanks a lot for the fast reply.
>
> The problem with storing something in the session is it that if the user
> tried to access two different pages at once in separate windows and had
> to login in both, he will be forwarded in both to the last page he tried
> to access. I think this is a quite realistic scenario, for example if a
> user was logged in and used the service in separate windows, but was
> kicked out by the system because he was inactive for a while. Any way to
> do that?
>
> Best,
> Anton
>
> Paul Benedict wrote:
> > Anton,
> >
> > Acegi Security does something similar. The original requests (yes -- the
> > actual request object) is stored in the session when the user's
> credentials
> > are challenged. If they then succeed at the login page, the original
> request
> > is taken from the session and forwarded along.
> >
> > Paul
> >
> > On 9/30/07, Anton Pussep <anton-ml@pussep.de> wrote:
> >> I spent quite a few hours today trying to forward the user to his
> >> original destination when he has to login in between.
> >>
> >> I have an interceptor (Authentication) that is called before an action
> >> and it forwards to Login.action if the user is not logged in. The
> >> problem is that if Login.action returns SUCCESS the struts.xml maps it
> >> to a static page (index.jsp) and not the page originally requested by
> >> the user.
> >>
> >> My current solution is it that the Authentication interceptor saves the
> >> requested URL as a session attribute and Login.action reads it and
> makes
> >> a getResponse().sendForward(requestedURL). However, I am not happy with
> >> this solution and I guess there are some much better solutions out
> >> there. Would be great if you could suggest me a better way to do that.
> >>
> >> Best regards,
> >> Anton
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: user-help@struts.apache.org
> >>
> >>
> >
>
>
> ---------------------------------------------------------------------
> 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