https://issues.apache.org/bugzilla/show_bug.cgi?id=46902
--- Comment #7 from Christopher Schultz <ch...@christopherschultz.net> --- As much as I like this kind of capability (particularly the addition of "landingPage" and something like the proposal to add "forceLandingPageAfterAuth"), I don't think is belongs in Tomcat because it's out-of-spec. I implemented a bunch of things in securityfilter to get around holes I saw in the spec and while tempted to bring them into Tomcat, discarded the notion because of that very fact (out-of-spec). I really hate product lock-in and it would be a shame for Tomcat to go down that path. Specifically, I implemented the following features in this area: 1. A landing page if there was no protected-page-access that caused the login form to be displayed (same as the "langingPage" feature) 2. The ability for the login page to accept a "next" page that would basically take the place of a "landing page", or override it 3. The ability for the client to specify whether or not the post-authentication action would be to REDIRECT or FORWARD to the landing page 4. The ability to pass request parameters to the login page which would then be forwarded to the landing page Some of this doesn't make sense unless you have very specific requirements (which we did). In our use-case, we had two web applications that share a URL space and one of them does not use sessions at all... it just passes-through the session-id of the other application when we make loopback-requests to the "other" application. If there's no session in the authenticated-application, we have to sent the user to a login page, but then have them sent back to the resource they were trying to access (which is in the non-authenticated application). So, we can't just send the user to the "protected resource" because that resource isn't directly-protected... instead, it's protected-by-proxy. It sounds outrageously stupid, but I promise it makes sense, and these features helped us pull it off. :) These days, with HttpServletRequest.authenticate() and HttpServletRequest.login() being available, it seems like all of the capability could be provided by a Filter on an unprotected resource rather than trying to shoehorn it into the existing authentication valve. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
