Hi all,
I’m using a setup in which we use mod_proxy to proxy site requests to ‘www-.xxx.nl’ and cms requests to ‘cms-.xxx.nl’. We’re using BrXM 13 and have recently stumbled upon https://issues.onehippo.com/browse/HSTTWO-4534. So, moved forward to the latest hotfix 13.0.0.-1
Now, everything appears to work way better than before. However, I still see an unexpected request in my proxy access_logs, causing the SSO handshake to fail. I’m (reverse)proxypassing / to 127.0.0.1/cms. So everything that goes to 'cms-local.xxxx.nl/’ in my case goes to 127.0.0.1/cms/
The relevant request, yielding a 404 is:
brxm-local-httpd-proxy_1 | 127.0.0.1 - - [17/Apr/2019:06:44:03 +0000] “GET /cms/auth?destinationPath=/site/_cmsinternal/?org.hippoecm.hst.container.render_host=…&cmsCSID=… HTTP/1.1” 404 1094
The render_host has a correct value, but what surprises me is that there is an actual /cms/ in the received path. I’d expected /auth here and Tomcat also yields a 404 page in the browser indicating a request path of /cms/cms/auth.
So it seems this URL is not generated by BrXM in a proxy-aware fashion. Replaying this request and removing ‘/cms’ manually, yields a successful login. As a workaround, I can start writing rewriterules specifically for this request, but I’d rather have a confirmation on this being error behavior and/or how to fix it without workarounds.
Can anybody confirm this behavior?
Thanks,
Brian
Allright, I’ve debunked/debugged my own issue by debugging the HstRequestUtils, taking org.hippoecm.hst.util.HstRequestUtils#getCmsBaseURL as a starting point.
Apparently, the finegrained control of hst:showport and hst:showcontextpath, as offered in hst:hst/hst:hosts does NOT WORK for hst:platform/hst:hosts nodes. While I set hst:showport and hst:showcontextpath on the most specific mount nodes in my site configuration in hst:hst/hst:hosts/… , I literally copied that to my hst:platform cms nodes. However, the hstPlatformModel loader completely ignored the fine-grained (most specific) setting on my plaformmounts and ALWAYS resorted to the hst:showport and hst:showcontextpath setting on the highest level (i.e. the hst:platform/hst:hosts node itself).
Is this expected behaviour? Or should fine-grained control be possible on hst:platform/hst:hosts/… nodes?
For me this works now, but clearly you don’t really expect the hst:hst and hst:platform to behave differently. My suggestion, if this is intended and not a bug, is to thoroughly document this somewhere, since developers expect this to work consistently (as before).
Kind regards,
Brian
We found out this again brings another problem to the table when trying to override hst:showcontextpath and hst:showport for localhost. We’ve submitted a bug ticket for it: https://issues.onehippo.com/browse/HSTTWO-4585
Hey Brian,
I am a bit curious about your setup since we also run the cms on / and use a reverse proxy.
Can you share me a dump of the host setup you have for ‘hst:hst’ and for ‘hst:platform’? And also the mod proxy configuration?
I’ll take a look at https://issues.onehippo.com/browse/HSTTWO-4585 . Since hst platform and site hst config are both loaded by the same code I’d be surprised if there is a difference, actually
Hey Jens,
I’ll take a look at the issue you reported and will give feedback there
1 Like