Uploading files is not working.
Files are not set in the action, there are no files in the request, and no
files detected by File Upload Interceptor (FUI).
Redirection Interceptor (RI) runs before the default stack FUI.
RI stores in session the request parameters before FUI has any chance to run.
When the time comes for the original request (default stack) it seems FUI has
no way to recover any "multipart" information. When RI restores original
'standard' parameters (
nvocation.getInvocationContext().getParameters().put(name, value) ) it seems
any multipart information is missing.
The question is: How can I save original multipart data and restore it when the
original action runs?
El Martes, 16 de julio de 2013 09:59:27 Antonios Gkogkakis escribió:
> You don't have to store text, you can store Object or even the File itself.
> it depend on where/when you extract the params from the original request
>
> Antonios
>
>
> On 16 July 2013 09:51, Antonio Sánchez <juntandolin...@gmail.com> wrote:
>
> > El Martes, 16 de julio de 2013 09:16:12 Antonios Gkogkakis escribió:
> > > Hi Antonio,
> > >
> > > I don't see anything different with the multipart requests, are you
> > > experiencing issues?
> >
> > I'll try to test multipart requests and will let you know. I must first
> > review file uploading. The potential problem I see is that I am only saving
> > in session text parameters. I don't know how binary data is transported in
> > the request. I headers are involved then they need to be saved too.
> >
> > >
> > > >>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
> >
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
