You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Ray Clough <ra...@allthisisthat.com> on 2007/05/16 03:27:47 UTC
Interceptor execution
I've got a large S1 app into which I'm putting S2 features - starting with a
LoginInterceptor, because the S1 security-implementation was NG. The S2
mapping in web.xml is to the url "/*", which I figured would catch all
requests, both from S1 actions and from S2 actions. The S1 Action servlet
is mapped to "*.do". It appears that the S1 actions aren't intercepted,
making the LoginInterceptor not work for them. How is "*.do" bypassing
"/*".
Is this really the case, or can something be done to force S1 actions thru
the S2 interceptor.
Thanks,
- Ray C.
--
View this message in context: http://www.nabble.com/Interceptor-execution-tf3762074.html#a10634231
Sent from the Struts - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Interceptor execution
Posted by Ray Clough <ra...@allthisisthat.com>.
I'm just mix-and-matching - not using S1 plugin. But the S2 Filter, mapped
to "/*" ought to catch all requests, because filters execute before
servlets. Therefore I wonder why the LoginInterceptor doesn't get executed
on S1-generated requests (ie. those with a *.do url, or even with a *.jsp
url). Perhaps the S2 Filter says "If the Request isn't mapped to *.action,
I won't process it at all". Does the S2 Filter really behave this way? If
that is how the filter behaves, is this configurable? Is there a
recommended way around it? (In S1 I subclassed the RequestProcessor, I'd
rather not subclass the Filter)
My own feeling is that I can write a filter which redirects all requests
without a login credential to "login.action", to force it thru the S2
processor, and so thru the LoginInterceptor, but then I'd be using a Filter
*AND* an Interceptor to accomplish the login. Perhaps I'll get rid of the
Interceptor and just do it with a Filter, but there are advantages to the
Interceptor which would be lost that way.
(by the way, Laurie, These are not the Droids you're looking for!)
- Ray C.
Laurie Harper wrote:
>
> Ray Clough wrote:
>> I've got a large S1 app into which I'm putting S2 features - starting
>> with a
>
> How? Are you using S2 with the S1 plugin? Or just putting both versions
> into one WAR and mix'n'matching?
>
>> LoginInterceptor, because the S1 security-implementation was NG. The S2
>
> NG? No Good? Next Generation? Nearly Ganked? ;-)
>
>> mapping in web.xml is to the url "/*", which I figured would catch all
>> requests, both from S1 actions and from S2 actions. The S1 Action
>> servlet
>
> There is no 'from', only 'too'. Too or too not. There is not from. Oops,
> have I been watching too much Star Wars? The point is, it doesn't matter
> where a request comes from; once it comes in, it's just a request. What
> happens next is based on the form of the request; in this case,
> specifically, the URL that's requested.
>
>> is mapped to "*.do". It appears that the S1 actions aren't intercepted,
>> making the LoginInterceptor not work for them. How is "*.do" bypassing
>> "/*".
>
> Given the request URL http://host:port/x/y/z.do, which pattern matches:
> /* or *.do? Obviously both patterns match. I'm not sure if the behaviour
> in this case is specified or not, but if it is then the order of the
> mappings is likely what determines which wins.
>
>> Is this really the case, or can something be done to force S1 actions
>> thru
>> the S2 interceptor.
>
> Err... not sure I understand the question. You can't have an S2
> interceptor applied to a request that's being handled by S1, since S1
> doesn't know about interceptors.
>
> I think you'd need to post a more concrete example of the sort of
> process flow you're trying to achieve and the configuration(s) you're
> trying to get there.
>
> L.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Interceptor-execution-tf3762074.html#a10645544
Sent from the Struts - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Interceptor execution
Posted by Laurie Harper <la...@holoweb.net>.
Ray Clough wrote:
> I've got a large S1 app into which I'm putting S2 features - starting with a
How? Are you using S2 with the S1 plugin? Or just putting both versions
into one WAR and mix'n'matching?
> LoginInterceptor, because the S1 security-implementation was NG. The S2
NG? No Good? Next Generation? Nearly Ganked? ;-)
> mapping in web.xml is to the url "/*", which I figured would catch all
> requests, both from S1 actions and from S2 actions. The S1 Action servlet
There is no 'from', only 'too'. Too or too not. There is not from. Oops,
have I been watching too much Star Wars? The point is, it doesn't matter
where a request comes from; once it comes in, it's just a request. What
happens next is based on the form of the request; in this case,
specifically, the URL that's requested.
> is mapped to "*.do". It appears that the S1 actions aren't intercepted,
> making the LoginInterceptor not work for them. How is "*.do" bypassing
> "/*".
Given the request URL http://host:port/x/y/z.do, which pattern matches:
/* or *.do? Obviously both patterns match. I'm not sure if the behaviour
in this case is specified or not, but if it is then the order of the
mappings is likely what determines which wins.
> Is this really the case, or can something be done to force S1 actions thru
> the S2 interceptor.
Err... not sure I understand the question. You can't have an S2
interceptor applied to a request that's being handled by S1, since S1
doesn't know about interceptors.
I think you'd need to post a more concrete example of the sort of
process flow you're trying to achieve and the configuration(s) you're
trying to get there.
L.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org