Thanks for the replies. The jsessionid/cookie tracking mode is not really
part of the problem, sorry about that.

Obviously I'm thinking about renaming the war but the rewriting is really
used, for example seo friendly urls like /bar/steps/1 internally rewrite to
/foo/somesubmodule/steps.jsp?step=1 and the system really can't expose
/somesubmodule/steps.jsp?step=1 as public urls, it messes with google
analytics stats or bookmarked urls.

As last resort I could move the apache RewriteRules to tuckey urlrewriter
under the war itself and just keep the ProxyPasses under apache.
Configuration & docs would be in a sole space.

I know that just because I /can/ do nasty rewriting stuff at the response
wrapper level I may not want to do it. The replies were useful ;)

regards


On Wed, Oct 4, 2017 at 9:58 AM, André Warnier (tomcat) <a...@ice-sa.com>
wrote:

> On 04.10.2017 07:40, Peter Kreuser wrote:
>
>>
>> Peter Kreuser
>>
>> Am 04.10.2017 um 02:44 schrieb Christopher Schultz <
>>> ch...@christopherschultz.net>:
>>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA256
>>>
>>> Laurant,
>>>
>>> On 10/3/17 5:17 PM, Laurent Perez wrote:
>>>> I'm using apache+mod_proxy+mod_rewrite as a tomcat frontend. A
>>>> "foo" war is deployed at /foo context path under tomcat. The /foo
>>>> path is not public, apache has a rewrite rule defined as : /bar/*
>>>> rewrites internally to /foo/*.
>>>>
>>>> I'm using jstl and its <c:url value="page.jsp"> for every url in my
>>>> jsps to gain the ;jsessionid from encodeURL whenever jsessionid
>>>> cookie is not yet set (1st requests)
>>>>
>>>>
>> adding to Christopher, accepting the jsessionid from the Url is a bad
>> security risk (Session fixation). So you should disable that by accepting
>> the session only via COOKIE via
>>
>> <session-config><tracking-mode>COOKIE</tracking-mode> </session-config>
>> then at least this rewriting problem is gone.
>>
>> Peter
>>
>>
> Well, a cookie can also be path-specific.  Which is only *one* of these
> issues which we are talking about, when we say "don't".
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


-- 
http://laurentperez.fr
J2EE, HTML5, JS, CSS3

Reply via email to