On 1:59 PM, Pid * wrote:
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
Hi, Jerry-
Pid makes a really good point. Protected URLs won't be indexed by the
search engines. And Konstantin's suggestion to use httpd to rewrite the
URLs seems like a fairly easy solution. You might also avoid a lot of
URL rewriting by using URLs like /products/PlasmaTVs and mapping
products.jsp to /products/* in web.xml.
-Terence Bandoian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
