Re: [ANNOUNCEMENT] Tomcat 3.2 Beta 7
[EMAIL PROTECTED] wrote: 6.8 Container Managed Security Constraints Due to the way that Tomcat 3.2 is implemented, container managed security constraints are imposed both on the original request URI *and* on subrequests initiated to handle RequestDispatcher.forward() or RequestDispatcher.include() calls. Since I did part of the implementation, my intention was to check the security constraints on forward and include. The reason - it's a huge security hole to not check them ( IMHO ) - a site running multiple webapps ( with different security constraints ) may be compromised if the constraints of the original requests are propagated on forward. ( you can get a request dispatcher for a different webapp - and then call include for a "secure" page ). Disabling access to other webapps is not allways possible or a good idea. It is certainly allowed to disable access to other webapps. The Javadocs for ServletContext.getContext() say: "In a security conscious environment the servlet container may return null for a given URL." In Tomcat 4.0, you enable this protection by saying crossContext="false" on your Context element. I'm going to add a similar option to 3.2. Of course, in 2.3 that seems to be required by the spec - I just hope I'm wrong and there is a way to avoid the security hole. If you don't want your JSP pages accessed directly (but only thrown a controller servlet in an MVC architecture, for example), the prescribed mechanism in 2.3 is to place them under a security constraint that has an auth-constraint element with no nested role-name elements. The container interprets this as "no direct access from clients", so the only access to such pages is through a RequestDispatcher (in a servlet) or jsp:include or jsp:forward (in a JSP page). Costin Craig McClanahan
Re: [ANNOUNCEMENT] Tomcat 3.2 Beta 7
6.8 Container Managed Security Constraints Due to the way that Tomcat 3.2 is implemented, container managed security constraints are imposed both on the original request URI *and* on subrequests initiated to handle RequestDispatcher.forward() or RequestDispatcher.include() calls. Since I did part of the implementation, my intention was to check the security constraints on forward and include. The reason - it's a huge security hole to not check them ( IMHO ) - a site running multiple webapps ( with different security constraints ) may be compromised if the constraints of the original requests are propagated on forward. ( you can get a request dispatcher for a different webapp - and then call include for a "secure" page ). Disabling access to other webapps is not allways possible or a good idea. Of course, in 2.3 that seems to be required by the spec - I just hope I'm wrong and there is a way to avoid the security hole. This does *not* seem to be the case. I have an example that uses the RD to forward() to JSP pages that are protected from direct access using BASIC authentication. It works exactly as it should: forward() invokes them but a direct access prompts for username/password. You may want to look at If this is the case probably something changed in the implementation, and we should at least find out if the danger is real and document that. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCEMENT] Tomcat 3.2 Beta 7
"Craig R. McClanahan" wrote: Hear ye! Hear ye! At long last, an updated "beta 7" release of Tomcat 3.2 is available for download, at: http://jakarta.apache.org/builds/tomcat/release/v3.2-beta-7 [...] Thanks a bunch Craig, and everyone else who helped out getting all the remaining bugs squashed. I have tested the stand-alone config with a lot of JSP examples (heavy on custom actions and beans) on Windows NT 4.0 with JDK 1.3, and everything works great! One thing though: the README file says in "Known Bugs" 6.8 Container Managed Security Constraints Due to the way that Tomcat 3.2 is implemented, container managed security constraints are imposed both on the original request URI *and* on subrequests initiated to handle RequestDispatcher.forward() or RequestDispatcher.include() calls. This does *not* seem to be the case. I have an example that uses the RD to forward() to JSP pages that are protected from direct access using BASIC authentication. It works exactly as it should: forward() invokes them but a direct access prompts for username/password. You may want to look at this again, and either clarify (if it's a special case that doesn't work) or remove this item from the list. I'll try to get a chance to run through some examples on Windows 98 and Linux as well tomorrow, just to make sure the startup scripts are okay and that there are no obvious platform dependent problems. Thanks again, Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
