Struts Hackathon in Germany
Hello all, I would like to invite you to a Struts Hackathon in Augsburg, Germany. The Hackathon is free, thanks to our sponsor of GFU. GFU provides a lot of great trainings. Please see more information here: http://strutsathon.opensource.io/ If you would like to join us, please let us know. There are currently 4 Struts PMC members confirmed to show up there. Our goal is to make Struts better and to help newcomers to work on Struts directly. If any questions, feel free to ping me directly or on this list. Thanks! Christian -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
[ANN] Struts 2.3.15.1 GA (fast track | security | critical)
The Apache Struts group is pleased to announce that Struts 2.3.15.1 is available as a "General Availability" release. The GA designation is our highest quality grade. Apache Struts 2 is an elegant, extensible framework for creating enterprise-ready Java web applications. The framework is designed to streamline the full development cycle, from building, to deploying, to maintaining applications over time. Two security issues were solved with this release, one of which is rated critical - see [1] and [2] for detailed information: * Remote code execution vulnerability when using short-circuit navigation parameter prefixes * Open redirect vulnerability when using short-circuit redirect parameter prefixes All developers are strongly advised to immediately update existing Struts 2 applications to Struts 2.3.15.1. Struts 2.3.15.1 is available in a full distribution or as separate library, source, example and documentation distributions, from the releases page. The release is also available through the central Maven repository under Group ID "org.apache.struts". The release notes are available online [3]. The 2.3.x series of the Apache Struts framework has a minimum requirement of the following specification versions: Servlet API 2.4, JSP API 2.0, and Java 5. Should any issues arise with your use of any version of the Struts framework, please post your comments to the user list, and, if appropriate, file a tracking ticket. - The Apache Struts Team. [1] http://struts.apache.org/release/2.3.x/docs/s2-016.html [2] http://struts.apache.org/release/2.3.x/docs/s2-017.html [3] http://struts.apache.org/release/2.3.x/docs/version-notes-23151.html -- René Gielen http://twitter.com/rgielen - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
RE: S2 custom authentication: remembering original request
On Jul 16, 2013 5:20 AM, "Martin Gainty" wrote: > > 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 That would mean if you redirected you'd be logged out every time. That would break every website in the world, and would render very common patterns like post-redirect-get useless. Dave
Re: S2 custom authentication: remembering original request
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
>
> mysuffix
> mymime/type
>
> -->
>
> 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 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 wrote:
> > > >
> > > > > The problem was I did not consider the namespace in the interceptor,
> > > > > config file and login action.
> > > > >
> > > > >
> > > > >
> > > > > ${#session.action}
> > > > > ${#session.space}
> > > > >
> > > > >
> > > > >
> > > > > 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 lo
Re: S2 custom authentication: remembering original request
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
In the interceptor. But the interceptor is not responsible of uploading. I
don't know how it works (uploading binary data), I must review first.
>
> Antonios
>
>
> On 16 July 2013 09:51, Antonio Sánchez 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 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
> > wrote:
> > > > >
> > > > > > The problem was I did not consider the namespace in the
> > interceptor,
> > > > > > config file and login action.
> > > > > >
> > > > > >
> > > > > >
> > > > > > ${#session.action}
> > > > > > ${#session.space}
> > > > > >
> > > > > >
> > > > > >
> > > > > > 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
> > >
RE: S2 custom authentication: remembering original request
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
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
mysuffix
mymime/type
-->
or in mime.properties
Martin Gainty
__
> 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 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 wrote:
> > >
> > > > The problem was I did not consider the namespace in the interceptor,
> > > > config file and login action.
> > > >
> > > >
> > > >
> > > > ${#session.action}
> > > > ${#session.space}
> > > >
> > > >
> > > >
> > > > 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, Antoni
Re: S2 custom authentication: remembering original request
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 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 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
> wrote:
> > > >
> > > > > The problem was I did not consider the namespace in the
> interceptor,
> > > > > config file and login action.
> > > > >
> > > > >
> > > > >
> > > > > ${#session.action}
> > > > > ${#session.space}
> > > > >
> > > > >
> > > > >
> > > > > 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
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Use Case: request some protected r
Re: S2 custom authentication: remembering original request
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 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 wrote:
> > >
> > > > The problem was I did not consider the namespace in the interceptor,
> > > > config file and login action.
> > > >
> > > >
> > > >
> > > > ${#session.action}
> > > > ${#session.space}
> > > >
> > > >
> > > >
> > > > 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
> > > > > > 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
Re: S2 custom authentication: remembering original request
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 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 wrote:
> >
> > > The problem was I did not consider the namespace in the interceptor,
> > > config file and login action.
> > >
> > >
> > >
> > > ${#session.action}
> > > ${#session.space}
> > >
> > >
> > >
> > > 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
> > > > > 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 po
Re: Extending Template
2013/7/9 Alireza Fattahi :
> Yes it is a typo.
> I have this in the
> struts.xml
Anyway, this constant isn't needed if you don't change the default
location ("template").
Right now there is a bit mess with theme support. Basically if you
want to change theme globally you must copy all the parent templates
into the new template. You can always use theme per tag, like below:
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
-
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
Re: Error while using struts-jquery-plugin 3.6.0 + sitemesh-2.4.2.jar + struts 2.3.15
2013/7/15 Sreekanth S. Nair : > Sorry i didn get you. > > You mean directly under WebContant folder? Is like this the following > > struts2-core.jar/ template to WebContent/template > struts2-jquery-plugin/template to WebContent/template (as it is or static > and .flt should be in seperate folder ) Templates have to be on classpath. But links generated to static content in WebContent. Simply open source of generated page to see what I mean. Regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: json validation with utf-8 error messages
2013/7/15 Alireza Fattahi : > Hi, > > I used to save the messages.resources with UTF-8 encoding > and the showed correctly but the json validation > messages not! > > I saved mesages.resource with ansi encoding and chaned all strings from > native to ascii ( by http://native2ascii.net/ ) > the json validation messages displayed correctly but the name="some.text" /> did not show correct messages, just question marks. Could you post content of messages.resource (properties?!?!)? > I added <%@ page contentType="text/html; charset=utf-8" %> to the page and > now I have correct json validation messages AND > > I don't know is it best practice or not. Yes, it is. Regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
