Re: encodeURL, jsessionid and mod_rewrite ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Laurent, On 10/4/17 6:31 PM, Laurent Perez wrote: > 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. Let's take a typical use-case, here, where you have a beautiful URL that is lovely for SEO (which, by the way, seems like a fiction to me, since search engines don't give flying fig about the value of the URL) and makes flowers grow out of scrap metal. Let's make that URL https://example.com/what/a/great/url/just/gorgeous/hashtag/notsad So you rewrite that URL internally to: http://internal/RJdo10/8/2017/index.jsp?docId=5 Great, now the search engine has that nice URL and your application has a pile of garbage to deal with. The user sees the nice URL and they get their data. Awesome. Now, what do the URLs look like on the actual page? They look like this: Other pages you may like: Page 6 Page 7 Page 8 Page 9 Page 10 (Wasn't 1996 a great time to be on the web?) When the search engine goes to index your page, it'll get your beautiful URL from wherever it got it, but then it will get these really ugly ones on the page, too. So your "Page 6" now has an unsightly URL being leaked-out to your search engines. How do you fix that? Content-rewriting to the rescue! It'll be great, you can re-assign each page to another beautiful URL: PageID URL 6 https://example.com/astonishingly/well/written/URL 7 https://example.com/surpassed/our/previous/benchmark/for/beauty 8 https://example.com/getting/our/SEO/moneys/worth 9 https://example.com/CEOs/earn/every/penny 10 https://example.com/you/cant/make/this/stuff/up So, now you get to maintain a huge list of "nice" URLs and their mappings (in both directions!), plus you get the overhead of re-writing 100% of the content of your page while it's streaming back out to the client. What about HTTP redirects? Aw, shucks. Now we need to have another layer that checks all response headers to see if we need to rewrite THOSE. It becomes miserable, unwieldy, and generates huge amounts of excess heat performing all of these (IMHO) completely useless operations. What's the problem with the URL looking like https://example.com/myapp/index.jsp?docId=5 Maybe I just don't "get" the whole concept of "SEO"... I figure if you put content on your pages that doesn't suck and only contains the words that make sense, you'll get the ranking you deserve. Playing games with your URLs is just going to make more work for everyone. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlnaYM8ACgkQHPApP6U8 pFj11Q//TVhBEm+kBhjt/tVi//NQ1I0ISLs02/F3A0t6fOgYv86j2IMgM9GLaIiS yg5A5c/PIVIvcLfycssb8BWht9riVp0B8RVg8faeZkPnSCeK61dhylrPLwgKB7M4 eFoqZYKVqmKv0gMRSS3l+fAB0OKjM1LtBSBNpnJROeS5eIii3lOrACqFkiqCjy3p NMsPB5b9eA9ZJPVtZMjARTndpqwSI/L44DcW+dwVveUvK6rXzXzqjy7G5MCDs6gM ge51pqb9jd+oXd+Rnb6vKEN4JTn5mtDx7dKohpJDrqtFa0bwL1rxL5LLd/berFRD dc4s0K2relxywWsVtrZfgCsuyqMJ9FAv/V9nZhB/Z8vq2WBep92pv9e1zXPF8Ijw sbpx+23FKzOsIRe7o2Gj5yezEkno1Tgws1Q79W6TZZzsnRTOvrx2zdfrIh/e6zFC XJBuU5cYdEYRIV1JbIzeupOyQdKc9B7KEgFWuaMOkT/T5peMXTGLZ+7+/TW1r2Mb 8vQVpQbIox3qa/0Xw+n0fts9zxZqHRpBgLv0UTL8Zr7keMgAWS3whYZQ05iS8cdd W5Jnsl8ZeYWDeKzALwYgmWo3NdxBuHZJ7YuiB3XE1SeIpvQ3GLApBVabG+q205T2 B2d74VuioRgGMW6Gscu2zaGsQAjfFSoNxegGGChQBDqIZu9oU3g= =NWa9 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: encodeURL, jsessionid and mod_rewrite ?
On 4 October 2017 23:31:36 BST, Laurent Perezwrote: >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. Rewrites are not generally problematic. It is changing the context path that causes all the problems. Renaming foo.war to bar.war (or equivalent for you config) should be sufficient. Mark > >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) >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 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 >>> >>> COOKIE > >>> 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 >> >> - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: encodeURL, jsessionid and mod_rewrite ?
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)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 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 >> >> COOKIE >> 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
Re: encodeURL, jsessionid and mod_rewrite ?
On 04.10.2017 07:40, Peter Kreuser wrote: Peter Kreuser Am 04.10.2017 um 02:44 schrieb Christopher Schultz: -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 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 COOKIE 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
Re: encodeURL, jsessionid and mod_rewrite ?
On 04.10.2017 02:44, Christopher Schultz wrote: -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 for every url in my jsps to gain the ;jsessionid from encodeURL whenever jsessionid cookie is not yet set (1st requests) Now my question is : the 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. - -chris +1. I can only agree 100% with what Chris is saying above. The fact that you /can/ do these things at the front-end proxy level, does not mean that it is a good idea to do it. There are probably cases when you can *really* not do otherwise, and that's why these mechanisms are there. But doing this, brings endless other practical inconvenients, extra work, confusion, documentation issues, understanding issues 6 months later, support issues, etc. So, in a nutshell : don't do it. P.S. The annoying bit about recommendations such as the above, is that if you follow them, you will not even know how much work and hassle you have saved to yourself, and 1) you will not even feel thankful and 2) we won't have the satisfaction of saying later : "well, we told you so" ;-) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: encodeURL, jsessionid and mod_rewrite ?
On 4 October 2017 06:40:24 BST, Peter Kreuserwrote: > >Peter Kreuser > >> Am 04.10.2017 um 02:44 schrieb Christopher Schultz > : >> >> -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 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 > >COOKIE >then at least this rewriting problem is gone. ... to be exchanged for a problem with the cookie path. >>> Now my question is : the 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
Re: encodeURL, jsessionid and mod_rewrite ?
Peter Kreuser > Am 04.10.2017 um 02:44 schrieb Christopher Schultz >: > > -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 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 COOKIE then at least this rewriting problem is gone. Peter >> Now my question is : the 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. > > - -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 >
Re: encodeURL, jsessionid and mod_rewrite ?
-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 for every url in my > jsps to gain the ;jsessionid from encodeURL whenever jsessionid > cookie is not yet set (1st requests) > > Now my question is : the 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. - -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