tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Funk <>
Subject Re: Force Non-SSL
Date Mon, 06 Jun 2005 11:04:50 GMT
Almost. (I think)

You can't request any pages under /WEB-INF. Security constraints are only for 
the incoming URL - not urls obtained by getRequestDispatcher()


Duong BaTien wrote:
> On Thu, 2005-05-26 at 06:34 -0400, Tim Funk wrote:
>> From a config point of view no. The "simple workaround"
>>- Ditch the web.xml config for requiring SSL
>>- Create a filter which checks the scheme and URL - if the do not match what 
>>you desire - you can issue a redirect in the filter to https (or http) as desired
> Hello Tim and other tomcat 5.5.9 experts:
> If i understand you correctly, you propose:
>   1) set security constraint pages you want to run under ssl, such as:
>      <security-constraint>
>        <web-resource-collection>
>          <url-pattern>/WEB-INF/secure/*</url-pattern>
>          <http-method>POST</http-method>
>          <http-method>GET</http-method>
>        </web-resource-collection>
>        <user-data-constraint>
>          <transport-guarantee>CONFIDENTIAL</transport-guarantee>
>        </user-data-constraint>
>      </security-constraint>
>   2) Write a servlet filter to direct any url NOT under the
> pattern /WEB-INF/secure/* to the same url such as /public/123.jsp. Do
> you have this code handy and want to share with others?
> The result will be:
>   1) When a user requests a /WEB-INF/secure/logonSuccess.jsp the
> container will force the user with its logon FORM, if the user is not
> authenticated. If username/password is authenticated the page
> logonSuccess.jsp wil be served.
>   2) If you create a user session (e.g. a guestTag for collecting user
> activities) while user is NOT authenticated, and the container now
> authenticated the user after the request of logonSuccess.jsp, the
> servlet spec will guarantee that the session visible to developer code
> after login be the same session object that was created prior to SSL
> login so there is no loss of session information.
>   3) Since the security model does not apply to RequestDispatcher
> according to serlet spec, the container will serve other requests under
> standard http and NOT https as reported after the user was served the
> logonSuccess.jsp.
>   4) Only after the user is authenticated by the server, we can use
> getUserPrincipal(), isUserInRole() to integrate container authentication
> with programmatic authorization. Before that, only a generic guestTag
> for recording user activities.
> Do i miss something?
> Thanks
> BaTien

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message