search

omeka-s-modules / Datavis

GNU General Public License v3.0
2 stars 1 forks source link

force_canonical behind proxy creates CORS issue #33

Closed alexdryden closed 4 months ago

alexdryden commented 4 months ago

One of our Omeka S instances is run behind a reverse proxy. We noticed that requests for data initiated from the DataVis module are sent to the backend application server directly, instead of to the reverse proxy, which creates a CORS problem that I've had a hard time resolving.

What has worked is to change the value of force_canonical to false in the DatavisVisRepresentation::datasetUrl() and DatavisVisRepresentation::diagramUrl(). It looks like force_canonical causes the server url to be used, which in our case would be the url that was assigned to the backend application server and explains the issue we're experiencing.

I'm inclined to use this solution rather than continuing to iterate on the CORS based solution, but I'm not sure about the underlying rationale behind the behavior of force_canonical. Am I making a footgun by setting force_canonical to false? Any advice is much appreciated!

zerocrates commented 4 months ago

Just speaking from a more general sense, server URLs get used a couple other places, so if you're having a problem with this there are probably some other places that cause issues... some links in the REST API come to mind but there are a few places they're used.

It's possible to configure your reverse proxy to pass along the Host header the client used, so the internal server sees its hostname as the correct "external" one when it comes to making absolute URLs. But, I appreciate that making configuration changes to a reverse proxy might be difficult or just not allowed at all in many cases.

You can see a general discussion of the "behind reverse proxy" URL situation at this core issue: https://github.com/omeka/omeka-s/issues/1763 . One result of that discussion is, I have a module https://github.com/zerocrates/ServerUrlOverride that lets you just set manually what the server URL should be; using that and setting it to the intended public hostname should resolve this, and any other absolute URL issues you unknowingly may have.

alexdryden commented 4 months ago

Thanks @zerocrates, that is really helpful! It looks like at one point there was an Apache substitute directive that changed the host url to the proxy url, and that method is still being used for some other applications behind this proxy, but at some point it was commented out for Omeka. Setting the host with an HTTP header sound like a better idea.

In the meantime I'll use the ServerUrlOverride module. Many thanks!