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:

> -----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
>
>

Reply via email to