On 4 October 2017 06:40:24 BST, Peter Kreuser <l...@kreuser.name> 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.

... to be exchanged for a problem with the cookie path.


>>> Now my question is : the <c:url> results in a
>>> "/foo/page.jsp;jsessionid=..." I want the result instead as
>>> /bar/pages.jsp;jsessionid=....
>>> 
>>> Should I go straight for a HttpServletResponseWrapper replacing
>>> every /foo/ with /bar/ or is there a more elegant way ? If the
>>> apache rewrite rule is modified - say, to /barv2/, is it ok to use 
>>> mod_headers to pass the original path instead of hardcoding /bar/
>>> ?
>> 
>> You are going down a path that will produce endless problems, hacks,
>> and ugly solutions to those problems. It will be much easier for you
>> to simply re-name your application from "foo" to "bar" and not worry
>> about any of this rewriting foolishness.

Huge +1

Mark


>> 
>> - -chris
>> -----BEGIN PGP SIGNATURE-----
>> Comment: GPGTools - http://gpgtools.org
>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>> 
>> iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlnULvMdHGNocmlzQGNo
>> cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFjrIw//fPYMRXFyX4Ad4Qcl
>> f6H2XjoFU7zOH9sQXjj5KgDL+DWS2nMH20RWes74ehYNv3BGDLIsv4CHClessOhW
>> f7euy0y18IAhnTGjUaP3WjbN6xt2M6UgWsIv2jxS30DdI6irZ8/9IWdZ4xy8PNWV
>> OujeuQBWniQH6jPVUwQ17qapiBDbAzB58HXb72KYFDj+Z6C0gacK/MT9yTkiNEX/
>> bFNucLH2oTMomRcNeGZsmWCmQ+jShx0bMjmaKX5JndtckRCWSG8bAZYBhq5JA+bd
>> GlFk/jZl+PT0cO1q6ViHvv9r3DDIUAMXvfvQnf6RciQ86GB+GrJn/GnRtPo7R5RH
>> MoNRr7H16XBXER1SlzjXHLd2HOKf5pFduG1lgwY1z4OWKdqHY39/bSJynfCjyiNC
>> VAvlZZQ2tCudwa+7Pit85FryW4HWECvw10vwYNLHDfFD63juI6YexaN+Fd5RGu8R
>> jGqN3GqR1iboveGTv8O2kSvTgJjGa0nxsd6CTZLMJXt1GPlZ4r9MRdZWO/dobvGt
>> QV18dvwHYHo1Jsgo1+pR6Hw34hw0dPfD5IYiHV9k+9yIeWj3l4/tYu+k1VA9j/Yp
>> /LJ6otvJ+zBaa2swroy+EnnbMP6JR04GnXrezglXxbndaP1l7POCFngH34veM4+S
>> j/5ZMvfJiUZdDAdQxoFH6B9ochU=
>> =0zb2
>> -----END PGP SIGNATURE-----
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: 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

Reply via email to