On 25 Dec 2011, at 22:03, Jerry Malcolm <2ndgenfi...@gmail.com> wrote:
> 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. Argh. 99% of SEO types = snake oil salesmen. Next they'll be organising back link swaps with entirely unrelated other websites (who happen to be their clients). > So that requirement has officially > flowed downstream to me.... May I inquire as to why public, indexable URLs are also protected with various types of admin access? If they need a login to access them, no search engine will be able to index them anyway... p > 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: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Jerry, >> >> 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. >> >> - -chris >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG/MacGPG2 v2.0.17 (Darwin) >> Comment: GPGTools - http://gpgtools.org >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >> >> iEYEARECAAYFAk7zq/UACgkQ9CaO5/Lv0PAd/wCfX2zAQ0PMQqCeogRzEs7WBEmB >> 3LcAniZ2m3TWCY7OczBa2zCDv85MzOdc >> =j2sU >> -----END PGP SIGNATURE----- >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
