2011/12/26 Jerry Malcolm <2ndgenfi...@gmail.com>: > Thanks for the input. This has turned into something really ugly. Let me > go back and summarize the situation: > > I have an established large application made up of about 10 separate > webapps (contexts) to keep it modular. Within each context there are 3-5 > user roles with varying authority. I organize the jsps in each webapp > based on roles and then set the security constraint to be, for example, > > -- for webapp ABC > -- 'ABCadmin' role for /jsp/admin/*.jsp, > --'ABCoperator' role for /jsp/operator/*.jsp in the ABC webapp. > > Likewise, for webapp XYZ > -- 'XYZadmin' role for /jsp/admin/*.jsp in the XYZ webapp, > -- etc, etc > > This has worked fine for years and I have sold this to the client as being > highly secure. No problems. > > Now, the client's SEO advisor has told them that they have to get rid of > the 'geeky stuff' like /ABC/jsp/guest/aaaaaa.jsp in the URLs and replace > them with SEO-friendly 1-word URLs. So that requirement has officially > flowed downstream to me.... > > So... I wrote a filter (implements javax.servlet.Filter) that takes > SEO-friendly words in the URL and map them to a particular context and path > to the appropriate JSP and uses a RequestDispatcher to forward the > request. I have the filter installed in a special webapp that is mapped to > "/" and therefore will receive all requests to the host. In the filter I > look up the mappings and then use cross-context functionality to route to > the appropriate context/path. No problems with the filter routing as far > as getting the request to the intended target. > > Example: /showPlasmaTVs = > /webAppContext1/jsp/user/products.jsp?productSearch=plasma > > I understand from this discussion that I now have zero security role > protection. I understand why. But that doesn't solve the problem. > > It appears that I have no really good options now: > > 1) make SEO happy and discard security > 2) make security happy and discard SEO requirements > 3) make everything a redirect.... which probably is the same as #2 since > URLs are now exposed > 4) write code myself to basically re-implement the entire functionality of > Tomcat's security system > > Let's start back from the top.... maybe I'm approaching the problem > completely incorrectly. I have a hard time believing I'm the first Tomcat > user ever that wants to completely hide ugly URLs and still utilize the > existing context security role structure. > > I'll start over with the question.... > > --- I want the user to see the URL: /showPlasmaTVs > > -- I want it to map internally to: > /webAppContext1/jsp/user/products.jsp?productSearch=plasma > > -- I would like for it to utilize the existing defined (and tested/proven) > security mappings that are based on the context/paths of the webapps. > > -- or if I have to write code to modify security handling, I don't want a > 3-month development project writing/testing a security module. > > How should I implement it? > > SURELY other Tomcat users have had this requirement...(?) > > Thx. > > Jerry > > > > On Thu, Dec 22, 2011 at 4:15 PM, Christopher Schultz < > ch...@christopherschultz.net> wrote: >> On 12/21/11 3:55 PM, Jerry Malcolm wrote: >> > The rewrite filter is correctly rewriting the URLs and forwarding >> > the requests. >> >> Any option to redirect? That would solve everything. >>
1) Do URL rewriting in front of Tomcat: e.g. at Apache HTTPD using mod_rewrite. I think that is the easiest. 2) Use client-side redirects, as Chris mentioned. The downside is that it exposes "internal" URLs to clients. 3) Write a Valve that has access to Tomcat internals. YMMV. I think that with a Valve there might be two ways, though I have not tried any of them. a) I think it can perform mapping and dispatch to a different Сontext as if the request came from the outside, so that its authentication constraints were applied. b) I think it can perform authentication checks using the constraints configured in web.xml of another web application. (See AuthenticatorBase). Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
