Giters

seashell / drago

☁️ Securely connect anything with WireGuard® and manage all your networks from a single place.

Home Page:https://seashell.github.io/drago

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Base URL option

mikkel1156 opened this issue · comments

commented

Wanting to try Drago in my setup I've created my own docker image to spin up (based on the build process found here), but it won't do API calls properly.

The issue is that it's expecting it to be run from localhost, so all API calls in the UI is trying to send to http://localhost:8080 - so it seems you can only use the UI if you're actually running it locally, and accessing UI locally.

Is there an option to change this in some way? I can't find it in the docs at least. Because if not I don't see how I'd get it working with my proxy either.

commented

Seems to be because it's hardcoded here: https://github.com/seashell/drago/blob/master/ui/src/environment.js
Any reason for this or just for easy testing?

commented

Thanks for reporting this. We need to set API_URL based on the configurations passed to Drago, namely BindAddress and Port. I see two possibilities for achieving this: (1) we switch to SSR, and (2) we have the UI fetch a file containing the address of the API from the server, with this file being created dynamically based on the Drago configs. Is there any drawback you see with any of these approaches? Can you think of any other alternative?

commented

A quick and easy solution is simply to remove the http://localhost:8080 so it's just '' - that way it will use whatever the server is hosting from. This is since it doesn't need the full path, but a relative one is fine (which it becomes /api/....). I just tested this in my own pipeline and can confirm it works (though you may want to confirm it's fine when testing though).

Relating to the other solutions, if you mean by SSR to switch away from React and instead do it with templates or something, then I don't think it's worth it. I think the solution Drago has right now is fine, just that the UI was expecting to query the localhost always. Solution two I think isn't very elegant. If we can find a way to have it not expect to always run on localhost, that would be fine.

I'm guessing it's hardcoded in for testing UI and API side by side? Could still have that option, but would need to set REACT_APP_REST_API_URL environment variable to http://localhost:8080 when developing then. Or have some kind of way to set when React is in "dev" mode, that it will default to http://localhost:8080 and just empty when not.

commented

Thanks for your reply. I didn't realize that simply setting the variable to '' would do the job. I will test your solution and if I don't find any further issues, we can incorporate it in the next release alongside a dev flag. In case you are willing to submit a simple PR yourself, that would too be awesome. In the meantime, feel free to reach out in case you run into any other issues or would like to discuss specific features.

Regarding the other solutions: by SSR I didn't mean switching away from React. We would just be moving the rendering to the server. When it comes to solution two, I agree it is not ideal.