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 r
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
se);
>
> Mime-mappings are set in web.xml as seen here
>
> mysuffix
> mymime/type
>
> -->
>
> or in mime.properties
>
>
> __________________
>
>
>
>
> > Date: Tue, 16 Jul
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
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
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,
> >
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
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:1
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 orig
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 intercepto
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 r
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), con
AFAIC, chaining interceptor is included in the default stack.
Anyway I have added it and still same result.
I'll try Rahul comments and will let you know.
El Viernes, 12 de julio de 2013 13:05:10 Antonios Gkogkakis escribi
Have you added the Chaining interceptor ?
Antonios
On 12 July 2013 12:41, Antonio Sánchez wrote:
> El Viernes, 12 de julio de 2013 12:33:43 Antonios Gkogkakis escribió:
> > try
> > request.setAttribute("url",invocation.getInvocationContext().getName())
> in
> > your interceptor.
>
> Same re
El Viernes, 12 de julio de 2013 12:33:43 Antonios Gkogkakis escribió:
> try
> request.setAttribute("url",invocation.getInvocationContext().getName()) in
> your interceptor.
Same result. Even using "invocation.getProxy().getNamespace()".
>
> Antonios
>
>
> On 12 July 2013 12:03, Antonio Sán
try
request.setAttribute("url",invocation.getInvocationContext().getName()) in
your interceptor.
Antonios
On 12 July 2013 12:03, Antonio Sánchez wrote:
> I'm having problems with chaining. I have tried several ways but none
> works. For instance:
>
> 1. http://localhost/mycontext/secure/pro
I'm having problems with chaining. I have tried several ways but none works.
For instance:
1. http://localhost/mycontext/secure/protected => Login.jsp (${#request.url} is
readable in jsp).
2. Login.jsp => submit (correct user/pwd) => ERROR: Infinite recursion
detected: [//authenticate!authenti
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
That doesn't do what you want because by not specifying the result type,
the dispatcher result is used and it's trying to serve
the /authenticar resource, which doesn't exist.
> >>
> > > /autenticar
> > >
> > >
> > > http://localhost:8084/mycontext/forward => 404 ERROR -
> >
El Miércoles, 10 de julio de 2013 10:14:55 Dave Newton escribió:
> Or configure the server to run forwards through the filter.
Sorry, I don't understand.
> On Jul 10, 2013 10:08 AM, "Paul Benedict" wrote:
>
> > Forwarding to another action means you want to do chaining:
> > http://struts.apac
Or configure the server to run forwards through the filter.
On Jul 10, 2013 10:08 AM, "Paul Benedict" wrote:
> Forwarding to another action means you want to do chaining:
> http://struts.apache.org/release/2.3.x/docs/action-chaining.html
>
>
> autenticar
>
>
>
> On Wed, Jul 10, 2013 at 10:
Forwarding to another action means you want to do chaining:
http://struts.apache.org/release/2.3.x/docs/action-chaining.html
autenticar
On Wed, Jul 10, 2013 at 10:00 AM, Antonio Sánchez
wrote:
> Can't forward even without using global results:
>
> http://localhost:8084/mycontext/autentic
Can't forward even without using global results:
http://localhost:8084/mycontext/autenticar => login.jsp - OK
/autenticar
http://localhost:8084/mycontext/forward => 404 ERROR - /mycontext/autenticar
not available
Which is the right way to forward to a
El Miércoles, 10 de julio de 2013 13:00:44 CRANFORD, CHRIS escribió:
> It should definitely be possible because what you described is out of the box
> functionality in Spring Security where their concept of intercepters is a
> filter.
How can I remember the original request? Piece by piece? I ca
> Second question: because it's a redirect, hence a new request.
http://localhost:8084/mycontext/autenticar => login.jsp - OK
Returned by interceptor:
/autenticar
http://localhost:8084/mycontext/admin/protected => 404 ERROR -
/mycontext/autenticar not available
H
It should definitely be possible because what you described is out of the box
functionality in Spring Security where their concept of intercepters is a
filter.
I would recommend that if you need a complete authentication and permissions
checking functionality to look into Spring Security. We h
Second question: because it's a redirect, hence a new request.
Dave
On Jul 10, 2013 7:28 AM, "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 (redirectActi
27 matches
Mail list logo
