search

omeka / omeka-s

Omeka S is a web publication system for universities, galleries, libraries, archives, and museums. It consists of a local network of independently curated exhibits sharing a collaboratively built pool of items, media, and their metadata.
GNU General Public License v3.0
401 stars 134 forks source link

Welcome e-mail ignores proxy settings #865

Closed crism closed 2 years ago

crism commented 7 years ago

We’re running Omeka S behind a proxy; the system is running on e.g. omeka-server.example.org, but users visit and interact with https://service.example.org/omeka/. When new accounts are created, the welcome e-mail directs users to https://omeka-server.example.org/, which is not reachable.

I can’t find any way to configure the canonical address used for welcome messages (or other messages); seems like this is a needed feature.

zerocrates commented 7 years ago

Do you know if your proxy is passing along an X-Forwarded-Host header? There's a preexisting feature of Zend's canonical URL generator we should be able to expose if that's the case that makes it respect that header.

The base path we may just need to expose in configuration... I don't think there's any good way for us to automatically figure out that the proxy has a different base path than the instance.

crism commented 7 years ago

Thanks, @zerocrates—I’ll check on that. Most of the other tools we’re configuring in our scholarly publishing suite have a configuration setting for the canonical address, and it seems to work pretty well…

crism commented 7 years ago

Yes, @zerocrates, X-Forwarded-Host is being sent, and set correctly. I’ll keep poking at the code (this seems to be with how Omeka S uses ZF2, so reading docs now), but any ideas on your side are most welcome.

zerocrates commented 7 years ago

I've poked around at it a little bit and... we'll see.

Zend Framework 2/3 doesn't make this a simple thing to configure: the base URL (scheme, hostname, port, etc.) and base path are often set independently and in different places: there are different helpers for getting the base path or base URL prepended to the URLs Omeka generates, and each seems to hold its own copy of that information. One place has built-in configuration that can be used already (the BasePath helper), but most others do not and would need us to provide some glue between a configuration setting and the actual component.

The most problematic piece is probably the router: it does have a method for setting the base URL, but that affects both matching of URLs coming in and production of URLs going out. In the proxy situation we want to change only the produced URL but have the incoming ones be processed as normal, since the proxy is converting the incoming URLs already.

The X-Forwarded-Host header is helpful, but even that is limited as far as I can see. There's a switch in the ServerUrl helper to respected those "X-Forwarded" headers to tell what the real public hostname is, but there doesn't seem to be equivalent support in the router, and it's in the router that we produce many of our absolute URLs.

I keep thinking that I'm missing something in Zend's code that will make this work more smoothly but it's feeling unlikely...

crism commented 7 years ago

This SO question seems useful. The serverUrl(), getRequest(), and setBaseUrl() methods might each be helpful… I need to keep reading, but setting the base URI to use the canonical proxy request at the start of a transaction should cause future calls to Url() to do the right thing.

zerocrates commented 7 years ago

The problem is, setting the base URL on the router also changes how it tries to figure out what URL to route to within the application. So, if you set it to something where the path is different, you get a bunch of 404 errors when it tries to actually do its work to send you to the right controller/action.

The other problem is that there's a fair amount of stuff that generates urls that doesn't use Url (like links to static assets), so those have to be handled separately, but that's not as important or difficult.

crism commented 7 years ago

Ah, hm. The links (internal links, stylesheets, scripts, etc.) are handled by our proxy rewriter, so it’s really just non-HTTP(S) renderings of URLs that are a problem. I think that just means e-mail, so maybe just a configuration switch there…

zerocrates commented 2 years ago

Some later changes (in Omeka S 3.1.0 and later) have made it feasible to manually configure the server URL that Omeka uses when generating absolute URLs like these.

At the moment there's a module that allows that configuration, and we may look at integrating that functionality into the core directly.

See #1763 for more information.