El Martes, 16 de julio de 2013 05:20:05 Martin Gainty escribió: > be careful when storing params into session during redirect > > remember redirect invalidates the original session and creates a brand new > session from client's browser
It's working in my test (Tomcat). The question is: does a redirectAction result invalidate the session? If it doesn't I can safely use session. > > Best to tuck away the old parameters anywhere but in the session > > then construct redirect with Location header pointing to the new action > (appending the old parameters) > > when constrcuting a response with an specific mime-type remember the > ContentType must be set in the response e.g: > response.setContentType("application/octet-stream"); > > then pass to filters in your chain: > chain.doFilter(request, response); > > Mime-mappings are set in web.xml as seen here > <mime-mapping> > <extension>mysuffix</extension> > <mime-type>mymime/type</mime-type> > </mime-mapping> > --> > > or in mime.properties > > > ______________________________________________ > > > > > > Date: Tue, 16 Jul 2013 09:16:12 +0100 > > Subject: Re: S2 custom authentication: remembering original request > > From: gkogk...@tcd.ie > > To: user@struts.apache.org > > > > Hi Antonio, > > > > I don't see anything different with the multipart requests, are you > > experiencing issues? > > > > >>One more question: What should I do in case the original request is a > > multipart request? For instance: select picture -> click upload -> > > >>authentication -> upload action. > > > > > > On 15 July 2013 18:19, Antonio Sánchez <juntandolin...@gmail.com> wrote: > > > > > Hi Antonios. Thank you very much. > > > > > > I was using > > > > > > invocation.getProxy().getConfig().getParams() > > > > > > instead, but that returns an immutable map. It works using > > > getInvocationContext().getParameters(). Thank you. > > > > > > I have to say that I'm not chaining actions: it doesn't make sense to > > > remember the original request if Login.jsp result breaks the chain and, at > > > the end of the day, I have to code for remembering the original parameters > > > (in the interceptor). I'm using redirectAction. > > > > > > One more question: What should I do in case the original request is a > > > multipart request? For instance: select picture -> click upload -> > > > authentication -> upload action. > > > > > > > > > El Lunes, 15 de julio de 2013 10:29:26 Antonios Gkogkakis escribió: > > > > 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 > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > 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