On 4 October 2017 23:31:36 BST, Laurent Perez <l.lauren...@gmail.com> wrote: >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) <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 >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
