On 26 Dec 2011, at 22:27, Jerry Malcolm <2ndgenfi...@gmail.com> wrote:
> Half of the site is protected, and the other half is not, and some pages > have moved from unprotected to protected at the whim of the client. How on earth are you supposed to meet all of these requirements? If you want to have a sane security scheme then you will have to make it clear to your client that all things are not possible at the same time and they will have to choose from a list of compromises. Right now you are up against limitations that you are imposing on yourself. We can't fix that. If you can't simplify the requirement then you will need a more complex security layer. You can either write this yourself, or use an existing component like Spring Security*. It is not too hard to write a Filter based controller/router with integrated security. If you were to embark on this, I would recommend you take a thorough look at what you have already and consider what you can reuse and what you can't - you are effectively working to a whole new requirement. p * Disclaimer: I work for SpringSource. > The > client has simply stated "clean URLs". I have argued that point, and > lost. So independent of valid substantiation for the requirement, it is > what it is, and I'm not getting paid for arguing that point. > > I know I could protect all of the inbound URL aliases. But first of all, > it defeats the whole modularity design for my system. Roles are webapp > specific and definitions are contained in the web.xml file, and are folder > based. If I protect the inbound urls, I now have to have an entry for > every page in every web context all listed in the router filter web app > that sits at "/" instead of contained with the webapp web.xml. This is a > maintenance nightmare and a recipe for disaster when one page is > accidentally omitted from protection. > > I know there are solutions. But every one ends up being baling wire and > duct tape. All I want to do is take URL-A and change it to URL-B and have > it look to all of Tomcat like it came in as URL-B from the user. I know > that is basically httpd mod_rewrite. But as I stated earlier, I have some > dynamic database-related mappings. I know little about mod_rewrite. Is > there any way to do Apache mod_rewrite with a java application? > > Thanks. > > Jerry > > On Mon, Dec 26, 2011 at 3:16 PM, Terence M. Bandoian <tere...@tmbsw.com>wrote: > >> 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 >>>>> 3LcAniZ2m3TWCY7OczBa2zCDv85MzO**dc >>>>> =j2sU >>>>> -----END PGP SIGNATURE----- >>>>> >>>>> ------------------------------**------------------------------** >>>>> --------- >>>>> To unsubscribe, e-mail: >>>>> users-unsubscribe@tomcat.**apache.org<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-unsubscribe@tomcat.**apache.org<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
