Hi Antonio,
You can't modify the parameter map from the Servlet request, but you can
pass the extra params from your first request to your action
by putting them in the struts parameters map by calling invocation.
getInvocationContext().getParameters().#put.
So to recap, you have your interceptor that catches the unauthorised
action, you store the uri and all the params you need in the session,
you redirect to the login page, and on login success you pass add the extra
params to the strut2 parameter map, and then struts will populate your
action.
Antonios
On 15 July 2013 10:16, Antonio Sánchez <juntandolin...@gmail.com> wrote:
> The problem was I did not consider the namespace in the interceptor,
> config file and login action.
>
> <action name="authenticate" class...>
> <result type="chain">
> <param name="actionName">${#session.action}</param>
> <param name="namespace">${#session.space}</param>
> </result>
> </action>
>
> Well, this is actually the easy part but the original question remains:
> How do I remember the original request parameters?
>
> When the flow is forwarded to Login.jsp the original request is lost. I
> can save the parameters map in session but when the time comes for the
> originally requested action (dynamic result) I don't know how to pass the
> original request parameters. I guess the right place to do it is the custom
> interceptor but I don't know how to pass parameters to the request. Is it
> possible to do?
>
>
> El Viernes, 12 de julio de 2013 17:39:59 usted escribió:
> > If I use "redirections" I will lose the original request(parameters,
> uploading binary data ...). But I am unable to make it work using forwards
> (chaining actions).
> >
> > I give up. I can't do his with S2. I guess this use case requires some
> external approach: servlet filter (as Dave pointed out), container managed
> security, Spring security...
> >
> > Thank you all for your support.
> >
> > El Viernes, 12 de julio de 2013 16:09:54 Rahul Tokase escribió:
> > > Hi
> > > Here is the way you can achieve this.
> > > You need to design login action to have the url 'redirectto' parameter
> > > which will holds the redirectaction. Upon login interception you will
> first
> > > check the login is done and then check for this parameter if there any
> > > value then simply forward to that action. else if login is required
> > > redirect it to the login page.
> > >
> > > If 'redirectto' url parameter is blank and login is success then
> forward it
> > > to the home page.
> > >
> > >
> > >
> > >
> > > On Wed, Jul 10, 2013 at 5:57 PM, Antonio Sánchez
> > > <juntandolin...@gmail.com>wrote:
> > >
> > > > Use Case: request some protected resource -> redirect action for
> > > > authentication -> access protected resource.
> > > >
> > > > I'm using a custom interceptor that redirects (redirectAction) to a
> global
> > > > result if no user object is found in session. The final action
> result then
> > > > redirects to a login page.
> > > >
> > > > The interceptor gets the original action requested (using
> > > > request.getServletPath(), but not sure if this is right), and puts
> it in
> > > > the value stack. It would be used with dynamic redirection in the
> final
> > > > result upon login success( ${nextAction} ) . This action must be
> passed in
> > > > between redirections.
> > > >
> > > > But I need to reuse the original request. Reconstructing the request
> with
> > > > a query string is not an option. I need the original request:
> GET/POST
> > > > method, all parameters/values, maybe uploading binary content
> > > > (inputstream), maybe headers...
> > > >
> > > > Is it possible to do this? How?
> > > >
> > > > ------
> > > >
> > > > Partially related to this: I'm having problems with redirections. The
> > > > original request parameters are forwarded only using dispatcher
> result . If
> > > > I use redirectAction or redirect, original params are lost. Why?
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
> > > > For additional commands, e-mail: user-h...@struts.apache.org
> > > >
> > > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
> For additional commands, e-mail: user-h...@struts.apache.org
>
>
>
