recommendation for hosting UI and backend on same host

[brainchild0]

Unlike many similar applications, Shlink maintains a package-level separation between the web UI and the REST backend. However, simple deployments may seek to place the combined system on a single host. The distributions of both package have no overlapping names at the top level, so one might consider unpacking both into the same location. Is this course recommended?

Otherwise, what recommendation is offered?

(Another possibility would seem to be putting the backend on a subdomain and exposing the UI on the main domain...?)

[acelaya]

Hey @brainchild0

Another possibility would seem to be putting the backend on a subdomain and exposing the UI on the main domain...?

If you really want to host them both, I would recommend using a subdomain for one of them, yes, but probably the other way around.

The backend is also de one serving short domains, so you probably want to keep them as short as possible, while having the web client under something like admin.example.com shouldn't be a problem as very limited users will have access to it.

In any case, there's something else you can do. Just host shlink and access to it through https://app.shlink.io. It is an app running 100% in the browser, so you are not leaking any confidential information.

That way, you can forget about updating the client. One less thing to worry about.

[brainchild0]

So the architecture is that the web client functions effectively as a standalone client application that happens to be served into the web browser?

This design choice is highly unusual. One issue is that the security rests on several assumptions whose correctness is unclear to the user, or administrator provisioning a deployment. A second, more direct, issue is that a typical use case is that a user might visit a web portal on a self-hosted site, enter login credentials, and then have access to the interface. Under the current model, access is only possible from clients that previously have been provisioned.

Overall, this design strikes me as less secure and more restrictive.

[acelaya]

Yes, it's true. The reason to choose this approach was to simplify maintainability for me (I wish I had more time to work on the project), but it certainly has some disadvantages.

[brainchild0]

Well, regardless, when I try to run, I get XSS complaints from the browser, which is not surprising. How does one normally circumvent this restriction?

[acelaya]

Shlink sends the CORS headers automatically, so you probably have something in between dropping them (a reverse proxy or something in those lines)

[brainchild0]

No, no proxy. I can't think of anything on my client that would have such an effect.

[acelaya]

What browser are you using? Can you paste a screenshot of the error that is displayed in the browser's console?

Can you try accessing your Shlink instance from https://app.shlink.io or https://api-spec.shlink.io and see if it works?

[brainchild0]

I revisited your previous comment, and realize that you suggested that a reverse proxy might cause the issue. It is true that the server runs a ngix reverse proxy in front of Apache. This configuration is rather typical of shared hosting solutions.

[acelaya]

Yes, I know. I also use a reverse proxy on front of my own shlink instances.

What I mean is that it's probably misconfigured, as it's removing the headers that shlink generates.

[brainchild0]

The configuration is handled by Plesk, which is an all-in-one package to help vendors selling shared hosting. Do you have experience with this solution?

[acelaya]

I'm afraid I don't

[acelaya]

As the original question has been answered, I'm closing this issue.

Feel free to open other tickets if needed.