Malformed CMS-authentication request when proxying on different CMS and HST domains

#1

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

#2

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

#3

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

#4

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

#5

Hey Jens,

I’ll take a look at the issue you reported and will give feedback there

1 Like