struts-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dean Pullen (JIRA)" <>
Subject [jira] Commented: (WW-2025) Action's can't be used for web.xml declarative security URL's
Date Sat, 03 Nov 2007 11:45:35 GMT


Dean Pullen commented on WW-2025:

I've removed

And instead forwarded the login to a login_redirect.jsp:


The login_redirect.jsp contains:

This all seems to work fine, but it's obviously still a slight fudge.

> Action's can't be used for web.xml declarative security URL's
> -------------------------------------------------------------
>                 Key: WW-2025
>                 URL:
>             Project: Struts 2
>          Issue Type: Improvement
>          Components: Dispatch Filter
>    Affects Versions: 2.0.8
>         Environment: Tomcat 5.5.23 (also present in the most recent 6.0.13 release),
Java(TM) SE Runtime Environment (build 1.6.0-b105), S2.0.8
>            Reporter: Jon Wilmoth
>             Fix For: Future
> Using an action URI for web.xml declarative security results in a 404 "The requested
resource (/mywebapp/login.action) is not available message." on Tomcat (both 5.5.x & 6.x).
 Representative XML configs below:
> <login-config>
>         <auth-method>FORM</auth-method>
>         <form-login-config>
>             <form-login-page>/login.action</form-login-page>
>             <form-error-page>/loginFailure.action</form-error-page>
>         </form-login-config>
>     </login-config> 
> <action name="login">
>     <result>/login.jsp</result>
> </action>
> Unfortunately it looks like the S2 architectural change from a Servlet to Servlet Filters
is the culprit.  After digging through the tomcat 5.5.23 (also present in the most recent
6.0.13 release) code I've come to the conclusion Struts2 actions CAN NOT be used for any of
the common web.xml descriptor elements (form-login-page, form-error-page, welcome-file?, other?).
 Here's a snippet of the javadoc from org.apache.catalina.core.ApplicationDispatcher's invoke
> * <strong>IMPLEMENTATION NOTE</strong>: This implementation assumes that
no filters are applied to a forwarded or included resource, because they were already done
for the original request.
> Since this worked in S1, I've opened this ticket as a BUG.  The workaround I received
on the user list of doing an HTTP meta REFRESH works, but results in screen flashing (even
with a refresh of 0 seconds) and a poor user experience. I'd GREATLY appreciate if one of
the Struts developers had a more elegant workaround suggestion.  For example would it be feasible
to port FilterDispatcher to a servlet?

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message