You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Jerry Malcolm <2n...@gmail.com> on 2011/12/21 21:55:14 UTC
Security Constraints With URL Rewrite filter
I structure my webapps with different JSP folders for different user role
access, and define the folder patterns in web.xml for each role access.
This has worked for many years in my webapps. But in the interest of
getting cleaner URLs, I've written a URLRewrite filter. The rewrite filter
is correctly rewriting the URLs and forwarding the requests. But I just
noticed something I hadn't counted on. The security constraints no longer
apply to the call to the rewritten URLs from the filter. In other words,
JSPs in /jsp/admin folder are configured to require "admin" role. But I
can call a JSP from inside the filter to /jsp/admin/myadmintask.jsp and no
security challenge occurs.
I guess this makes sense to me. I just wasn't expecting it. I assume that
the security constraint now applies to the pattern that come INTO the
filter. So instead of constraining /jsp/myadmintask/*.jsp in web.xml, I
now need to constrain the inbound url "/doadmin". Is that correct?
I just need some education here. Is it correct that should map all of the
URL patterns that come INTO the rewrite filter? Alternatively, is there
some way for me to do the requestdispatcher.forward call from the filter,
and tell it to honor security constraints on the folder structure like it
worked prior to adding the rewrite function?
Thanks.
Jerry
RE: Security Constraints With URL Rewrite filter
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Jerry Malcolm [mailto:2ndgenfilms@gmail.com]
> Subject: Security Constraints With URL Rewrite filter
> I assume that the security constraint now applies to the
> pattern that come INTO the filter.
Not sure what you mean by "now applies", but it's always that way.
> So instead of constraining /jsp/myadmintask/*.jsp in web.xml, I
> now need to constrain the inbound url "/doadmin". Is that correct?
Since we don't really know what your new URLs are, we can't say, can we?
> I just need some education here.
The first place to look to find out how things are supposed to work is the servlet spec; SRV.12.2 says:
"The security model applies to the static content part of the web application and to servlets and filters within the application that are requested by the client. The security model does not apply when a servlet uses the RequestDispatcher to invoke a static resource or servlet using a forward or an include."
(Admittedly, the above doesn't mention filters, but the intent appears to be that any use of RequestDispatcher is done after security constraints have been satisfied so that such use can retrieve otherwise inaccessible resources.)
> Alternatively, is there some way for me to do the
> requestdispatcher.forward call from the filter, and tell it to
> honor security constraints on the folder structure like it
> worked prior to adding the rewrite function?
Don't think so, since security constraints are applied very early in the request processing cycle, before any servlet/filter processing occurs. You could configure the UrlRewriteFilter to do a redirect instead of a forward - but that would expose the rewritten URLs to the client.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Security Constraints With URL Rewrite filter
Posted by Konstantin Kolinko <kn...@gmail.com>.
2011/12/22 Jerry Malcolm <2n...@gmail.com>:
> I structure my webapps with different JSP folders for different user role
> access, and define the folder patterns in web.xml for each role access.
> This has worked for many years in my webapps. But in the interest of
> getting cleaner URLs, I've written a URLRewrite filter. The rewrite filter
> is correctly rewriting the URLs and forwarding the requests. But I just
> noticed something I hadn't counted on. The security constraints no longer
> apply to the call to the rewritten URLs from the filter. In other words,
> JSPs in /jsp/admin folder are configured to require "admin" role. But I
> can call a JSP from inside the filter to /jsp/admin/myadmintask.jsp and no
> security challenge occurs.
Yes, constraints are applied to incoming URLs only.
One you have reached the web application, the web application itself
can forward/include jsps and servlets from any addresses inside of it.
One similar example (not related to authentication) is that you can
place JSPs into WEB-INF folder. Those will not be accessible from
outside, but they will be accessible when you programmatically forward
to them /include them. That is useful when using MVC design pattern .
If you want to be sure, try reading the Servlet spec.
http://wiki.apache.org/tomcat/Specifications
>
> I guess this makes sense to me. I just wasn't expecting it. I assume that
> the security constraint now applies to the pattern that come INTO the
> filter. So instead of constraining /jsp/myadmintask/*.jsp in web.xml, I
> now need to constrain the inbound url "/doadmin". Is that correct?
>
> I just need some education here. Is it correct that should map all of the
> URL patterns that come INTO the rewrite filter?
Yes. Though note that URL pattern matching in web.xml is less powerful
than the one in urlrewrite filter. Only prefixes or extensions. No
regexps.
> Alternatively, is there
> some way for me to do the requestdispatcher.forward call from the filter,
> and tell it to honor security constraints on the folder structure like it
> worked prior to adding the rewrite function?
You cannot trigger it from a filter. Maybe you can do from a Valve
(because it has access to Tomcat internals), but that would still be
tricky.
It is possible to use 3-rd party filters (or a custom filter) as a
replacement to container-manager security. Note that you have to
explicitly configure filter-mapping to match forwarded or included
requests (see the spec).
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Security Constraints With URL Rewrite filter
Posted by Chema <de...@gmail.com>.
Well, I don't know about this , but
What is the "URLRewrite" filter ? A Servlet filter ?
You can try to write a Valve and test if it works. I think it's
processed before calling container code. Maybe ...
Or to configure a proxy web to rewrite . I did't make this before, but
I know it's possible. If I find some info about this, I send it to you
Bye
2011/12/21 Jerry Malcolm <2n...@gmail.com>:
> I structure my webapps with different JSP folders for different user role
> access, and define the folder patterns in web.xml for each role access.
> This has worked for many years in my webapps. But in the interest of
> getting cleaner URLs, I've written a URLRewrite filter. The rewrite filter
> is correctly rewriting the URLs and forwarding the requests. But I just
> noticed something I hadn't counted on. The security constraints no longer
> apply to the call to the rewritten URLs from the filter. In other words,
> JSPs in /jsp/admin folder are configured to require "admin" role. But I
> can call a JSP from inside the filter to /jsp/admin/myadmintask.jsp and no
> security challenge occurs.
>
> I guess this makes sense to me. I just wasn't expecting it. I assume that
> the security constraint now applies to the pattern that come INTO the
> filter. So instead of constraining /jsp/myadmintask/*.jsp in web.xml, I
> now need to constrain the inbound url "/doadmin". Is that correct?
>
> I just need some education here. Is it correct that should map all of the
> URL patterns that come INTO the rewrite filter? Alternatively, is there
> some way for me to do the requestdispatcher.forward call from the filter,
> and tell it to honor security constraints on the folder structure like it
> worked prior to adding the rewrite function?
>
> Thanks.
>
> Jerry
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Security Constraints With URL Rewrite filter
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jerry,
On 12/26/11 5:26 PM, Jerry Malcolm 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. 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.
But you will be paid for making these changes. Why not tell the client
that this SEO "optimization" is going to cost them a whole bunch of
money to actually perform?
You may just have to suck it up and do the painful work of either
mapping everything or re-jiggering everything to read REST-looking
URLs instead of ones with complex query strings.
> 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?
There is a url-rewrite tool, but it's filter-based and will have the
same shortcomings of your own solutions up till this point. The
dynamic database-related mappings are going to kill you, here.
Occasionally, people ask about using Tomcat as an httpd proxy, the the
response has always been "other tools do it quite well, so Tomcat
doesn't have to" and the issue generally drops. On-the-fly
programmable rewrites aren't something I'm aware of.
You might find that mod_proxy_http can be configured to follow
(certain) redirects internally, so you can have your redirection-logic
in your Tomcat-based webapp, but the client never actually sees the
redirect. That would be very convenient.
- -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/
iEYEARECAAYFAk76HuwACgkQ9CaO5/Lv0PCwKgCeNLen0L4WRKmO3JYZpcX2s+Lm
mR0AnR+WXGLgBnf4naOWZhhf2yRsm8Zd
=482h
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Security Constraints With URL Rewrite filter
Posted by Pid * <pi...@pidster.com>.
On 26 Dec 2011, at 22:27, Jerry Malcolm <2n...@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 <te...@tmbsw.com>wrote:
>
>> On 1:59 PM, Pid * wrote:
>>
>>> On 25 Dec 2011, at 22:03, Jerry Malcolm<2n...@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<
>>>> chris@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<us...@tomcat.apache.org>
>>>>> For additional commands, e-mail: users-help@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<us...@tomcat.apache.org>
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Security Constraints With URL Rewrite filter
Posted by Jerry Malcolm <2n...@gmail.com>.
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. 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 <te...@tmbsw.com>wrote:
> On 1:59 PM, Pid * wrote:
>
>> On 25 Dec 2011, at 22:03, Jerry Malcolm<2n...@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<
>>> chris@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<us...@tomcat.apache.org>
>>>> For additional commands, e-mail: users-help@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<us...@tomcat.apache.org>
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Security Constraints With URL Rewrite filter
Posted by "Terence M. Bandoian" <te...@tmbsw.com>.
On 1:59 PM, Pid * wrote:
> On 25 Dec 2011, at 22:03, Jerry Malcolm<2n...@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<
>> chris@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-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@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
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Security Constraints With URL Rewrite filter
Posted by Pid * <pi...@pidster.com>.
On 25 Dec 2011, at 22:03, Jerry Malcolm <2n...@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 <
> chris@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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Security Constraints With URL Rewrite filter
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Jerry Malcolm [mailto:2ndgenfilms@gmail.com]
> Subject: Re: Security Constraints With URL Rewrite filter
> --- 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.
It's this constraint that you're imposing on yourself that's creating the problem. Why can't you revise the security mappings to use the URLs, not the servlets? At the same time, inhibit direct access to the old URLs.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Security Constraints With URL Rewrite filter
Posted by Jerry Malcolm <2n...@gmail.com>.
Thanks. That was the way I was doing it in the filter (getting the
dispatcher from the various contexts). I changed it. The good news is
that the routing now works as expected. The bad news is that it is still
bypassing the security stuff. I wasn't logged in, and it went straight to
the protected page anyway. Ideas?
Jerry
On Sun, Dec 25, 2011 at 6:58 PM, Konstantin Kolinko
<kn...@gmail.com>wrote:
> 2011/12/26 Jerry Malcolm <2n...@gmail.com>:
> > Konstantin,
> >
> > Thanks for the info. I think I'm getting close. As a test, I have
> created
> > a valve that just forces a redirect. It compiled fine. I registered it
> > under the 'host' tag next to the other valves in server.xml. When I
> send a
> > request in, my print statements write to System.out just as expected.
> >
> > The only problem is, the request forward goes nowhere. Just white screen
> > on the browser. The requestDispatcher returns without any exceptions.
> But
> > I can't find anything in the logs saying anything was wrong. The code is
> > simple:
> >
> > public void invoke(Request request, Response response) throws
> IOException,
> > ServletException {
> > System.out.println( "in Valve" );
> > try {
> > RequestDispatcher requestDispatcher = request.getRequestDispatcher(
> > "/cismanager/jsp/user/home.jsp" );
>
> In short,
> 1) dispatcher is always relative to Context.
> You must get Context first (from a Mapper?) and then get Dispatcher
> from there. (Dropping the "cismanager" part from the URL).
>
>
> If you were doing it from a Filter you would call
> ServletContext.getContext(String) followed by
> ServletContext.getRequestDispatcher().
>
> Note that ServletContext.getContext(String) returns null for better
> security, unless you explicitly set <Context crossContext="true"/> in
> the target web application.
>
> 2) using a RequestDispatcher you will get the same result as with
> using it from inside a Filter. That is it will be a usual "forward",
> and auth constraints wouldn't apply.
>
> Here are tips for debugging Tomcat:
> https://wiki.apache.org/tomcat/FAQ/Developing
>
>
> > System.out.println( "should get here" );
> > requestDispatcher.forward( request, response );
> > System.out.println( "return from forward");
> > }
> > catch( Throwable e) {
> > e.printStackTrace( System.out );
> > }
> > // getNext().invoke(request, response);
> > }
> >
> > I figure it's something to do with the URL. I have never used a
> > RequestDispatcher obtained from the Request object outside of a webapp
> > context. From what you said, the valve is 'above' the contexts at the
> > 'host' level. So I assume the parsing of the context out of the URL has
> > yet to occur and therefore should happen in my 'forward'. Hence, I used
> > the entire URL (after the domain name) in the forward. In the example
> > above, I have the webapp mapped to "/cismanager".
> >
> > Am I close? Or is this totally wrong? Should I not use the
> > RequestDispatcher? Should I somehow wrapper the request object and set
> the
> > new URL in that?
> >
> > Thanks again for all the help.
> >
> > Jerry
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Security Constraints With URL Rewrite filter
Posted by Konstantin Kolinko <kn...@gmail.com>.
2011/12/26 Jerry Malcolm <2n...@gmail.com>:
> Konstantin,
>
> Thanks for the info. I think I'm getting close. As a test, I have created
> a valve that just forces a redirect. It compiled fine. I registered it
> under the 'host' tag next to the other valves in server.xml. When I send a
> request in, my print statements write to System.out just as expected.
>
> The only problem is, the request forward goes nowhere. Just white screen
> on the browser. The requestDispatcher returns without any exceptions. But
> I can't find anything in the logs saying anything was wrong. The code is
> simple:
>
> public void invoke(Request request, Response response) throws IOException,
> ServletException {
> System.out.println( "in Valve" );
> try {
> RequestDispatcher requestDispatcher = request.getRequestDispatcher(
> "/cismanager/jsp/user/home.jsp" );
In short,
1) dispatcher is always relative to Context.
You must get Context first (from a Mapper?) and then get Dispatcher
from there. (Dropping the "cismanager" part from the URL).
If you were doing it from a Filter you would call
ServletContext.getContext(String) followed by
ServletContext.getRequestDispatcher().
Note that ServletContext.getContext(String) returns null for better
security, unless you explicitly set <Context crossContext="true"/> in
the target web application.
2) using a RequestDispatcher you will get the same result as with
using it from inside a Filter. That is it will be a usual "forward",
and auth constraints wouldn't apply.
Here are tips for debugging Tomcat:
https://wiki.apache.org/tomcat/FAQ/Developing
> System.out.println( "should get here" );
> requestDispatcher.forward( request, response );
> System.out.println( "return from forward");
> }
> catch( Throwable e) {
> e.printStackTrace( System.out );
> }
> // getNext().invoke(request, response);
> }
>
> I figure it's something to do with the URL. I have never used a
> RequestDispatcher obtained from the Request object outside of a webapp
> context. From what you said, the valve is 'above' the contexts at the
> 'host' level. So I assume the parsing of the context out of the URL has
> yet to occur and therefore should happen in my 'forward'. Hence, I used
> the entire URL (after the domain name) in the forward. In the example
> above, I have the webapp mapped to "/cismanager".
>
> Am I close? Or is this totally wrong? Should I not use the
> RequestDispatcher? Should I somehow wrapper the request object and set the
> new URL in that?
>
> Thanks again for all the help.
>
> Jerry
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Security Constraints With URL Rewrite filter
Posted by Jerry Malcolm <2n...@gmail.com>.
Konstantin,
Thanks for the info. I think I'm getting close. As a test, I have created
a valve that just forces a redirect. It compiled fine. I registered it
under the 'host' tag next to the other valves in server.xml. When I send a
request in, my print statements write to System.out just as expected.
The only problem is, the request forward goes nowhere. Just white screen
on the browser. The requestDispatcher returns without any exceptions. But
I can't find anything in the logs saying anything was wrong. The code is
simple:
public void invoke(Request request, Response response) throws IOException,
ServletException {
System.out.println( "in Valve" );
try {
RequestDispatcher requestDispatcher = request.getRequestDispatcher(
"/cismanager/jsp/user/home.jsp" );
System.out.println( "should get here" );
requestDispatcher.forward( request, response );
System.out.println( "return from forward");
}
catch( Throwable e) {
e.printStackTrace( System.out );
}
// getNext().invoke(request, response);
}
I figure it's something to do with the URL. I have never used a
RequestDispatcher obtained from the Request object outside of a webapp
context. From what you said, the valve is 'above' the contexts at the
'host' level. So I assume the parsing of the context out of the URL has
yet to occur and therefore should happen in my 'forward'. Hence, I used
the entire URL (after the domain name) in the forward. In the example
above, I have the webapp mapped to "/cismanager".
Am I close? Or is this totally wrong? Should I not use the
RequestDispatcher? Should I somehow wrapper the request object and set the
new URL in that?
Thanks again for all the help.
Jerry
Re: Security Constraints With URL Rewrite filter
Posted by Konstantin Kolinko <kn...@gmail.com>.
2011/12/26 Jerry Malcolm <2n...@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 <
> chris@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Security Constraints With URL Rewrite filter
Posted by Jerry Malcolm <2n...@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 <
chris@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Security Constraints With URL Rewrite filter
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org