In the past, we had some code in place to allow running foreman under a subfolder, for example https://example.com/foreman/ (instead of e.g. https://foreman.example.com).
However, that ability has been mostly broken for a long time due to many places in our react code that assume Foreman is running under the root URL (see for example Fixes #29893 - using properly prefixed URL in React by ezr-ondrej · Pull Request #7674 · theforeman/foreman · GitHub which tried to fix some cases).
Additionally, we generally require that Foreman runs on its own host with no other applications on it, so running in a subfolder doesn’t make much sense.
Some people suggested this might be useful for running a small POC, however I believe that forklift provides a much better experience for that and does not rely on a subpath mount.
In the 2-3 years that this ability has been broken, I have not seen any user complaining about issues caused by this, suggesting that this feature is not actually used at all.
Therefor, I propose to drop these attempts completely in Foreman 3.0 and officially consider this an unsupported setup. This will allow simplifying a lot of code around URL handling across the application.
Specifically, the main change from the developer standpoint in 3.0 will be marking the js foremanUrl will be marked as deprecated and return the same path it receives and will no longer be required.
If you object and believe this is something that we should invest in fixing, please also suggest how to achieve it and who will be able to undertake that effort.
I disagree with this part. IMHO it’s nice to have a helper for all Foreman URLs. That way you clearly mark all request that go to Foreman itself. I can also imagine that at some point we want to move to a real Single Page Application where the API runs on a different domain than the UI. Then it will be useful to know.
That said, we probably need to distinguish front end routing from backend requests.
If we drop this, we also need to remove support from the installer. We already did a major version release as preparation for 3.0 so it’d be a bit late to change it now.
I believe we can drop it from anywhere, and if we really want to do something like that in the future, it may be useful to add it to a centralized place like API middleware so the component that tries to do ajax call will always point to /example, but middleware will add a prefix for example.
If we “drop the support” and we don’t want to touch the installer code for 3.0, could we just modify the parameters documentation to explain it doesn’t work? If it’s broken for 2 years, it’d still be better than no change. Modules changes can probably wait a release or two after it’s declared unsupported or am I missing something?
