Have the docker image use a subpath by default

[Lockszmith-GH]

I've read the README.md as well as the closed issues about the limitation of making the subpath configurable without rebuilding the code (#317 is the last one) and I completely understand those.

What I'm suggesting is to have the docker image / default code setup so it is configured to a default subpath, one of the maintainer's choosing (suggestions that come to mind: shlink, manage, admin, app - but anything would work here).

The reasoning is (aka Pros):

• Configuring a redirect to said default sub path from the root of the domain is rather easy regardless of which reverse-proxy is being used.
• This would allow easy hosting on the same domain name, which will make browser based security guidelines easier to handle (everything will be within the same host-name, no cross domain issues)
• Will make the solution much more entry-level friendly for those with a single domain juggling multiple applications in different sub-paths.
• Customization, including completely removing the subpath will still be available in the exact same method it is available right now. (it might require a configuration of 'not-allowed keywords' on the shlink server, for completion)

The obvious con is that whatever the chosen subpath is, if hosted on the same server as shlink's server - it will not be usable as a slug (custom or random). I hope this is an acceptable price to pay for the convenience of easy hosting.

If I am completely out of line, feel free to close this issue.
However, I hope you find this reasonable enough to implement.

Thanks for creating an awesome set of tools.

[acelaya]

I'm afraid this is not going to happen, because it would introduce maintainability complexities with very little benefits.

Also, even though it might seem convenient for some use cases, I would find very counterintuitive to install a web application and have it work on a subpath only. Most users expectations would be to have it working in the root path, and changing that would only increase the number of complains from those who want it that way.

Ultimately, your list of "pros" is unconsciously biased:

Configuring a redirect to said default sub path from the root of the domain is rather easy regardless of which reverse-proxy is being used.

Configuring a reverse proxy to point to a subpath is as easy/hard as it is to point to the root. There's no difference there.

This would allow easy hosting on the same domain name, which will make browser based security guidelines easier to handle (everything will be within the same host-name, no cross domain issues)

Shlink is already configured to handle the CORS headers and everything always works out if the box even with different domains.

Will make the solution much more entry-level friendly for those with a single domain juggling multiple applications in different sub-paths.

Shlink's focus has never been entry level users. There are other alternatives for them.

Customization, including completely removing the subpath will still be available in the exact same method it is available right now. (it might require a configuration of 'not-allowed keywords' on the shlink server, for completion).

This is mostly a con, not a pro.

[Lockszmith-GH]

For some reason I never got the notification, so I want to start by thanking you for responding quickly to my original post.

As for the bias - I believe it is very consciously stated, nothing unconscious. I come with a bias based on my experience with successful installs of your app and others, as well as some unsuccessful installs.

Yours, is hands down, the best project out there for short links management, otherwise I wouldn't bother with suggesting changes to accommodate an even wider range of users.

But what I'd really want to do, is just address one of your replies in the hopes you will at least agree on that (doesn't mean you should accept my suggestion).

Configuring a redirect to said default sub path from the root of the domain is rather easy regardless of which reverse-proxy is being used.

Configuring a reverse proxy to point to a subpath is as easy/hard as it is to point to the root. There's no difference there.

The difference between adding a subpath to just stripping it is not negligible. They are not the same.

Removing something that is easily identifiable (a subpath), is much easier then deducing based on the incoming/outgoing traffic, whether a subpath needs to be added or not.

In anyway, I really thank you for this excellent project, and for your continued support of it. Regardless of my request, I will continue to use it.

[Lockszmith-GH]

I finally resolved the issue in a rather simplified manner.
Cross-referencing the solution from the show-and-tell discussion I've posted.

[webysther]

Solution with subpath: shlinkio/shlink#1837 (comment)