On Mon, 2005-06-06 at 07:04 -0400, Tim Funk wrote: > Almost. (I think) > Thanks. I will try the workaround and report to the list for the benefits of others.
BaTien DBGROUPS > You can't request any pages under /WEB-INF. Security constraints are only for > the incoming URL - not urls obtained by getRequestDispatcher() > > -Tim > I know. These are my protected pages and i want to make sure that they must go through my presentation engine (Jsf + Tiles). BaTien > 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 > >> > >> > >>-Tim > > > > > > 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 > > DBGROUPS > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
