No more separate frontend, proxy and window.API_URL

[ozuzo]

Description

Hi,

I'm running the latest version behind a proxy (shared server, cannot use port 80), using a .htaccess RewriteRule to proxy:

RewriteRule ^(.*)$ http://localhost:3456/$1 [P,L]

I now seem to run (sometimes? it worked for a while after upgrading? not sure what I did to make this happen) into the problem where the frontend is trying to connect to the wrong URL for the API. Looking at the page source, I see

window.API_URL = 'http://localhost:3456/api/v1'

In the previous versions, I see the (default?) value seemed to be

window.API_URL = '/api/v1'

and that worked like a charm.

Did I miss something where I can change the API_URL to be used now everything is in a single binary? I've set service.publicurl to the full URL used to access Vikunja in the browser (no /api/v1)

Thanks!

Vikunja Version

v0.23.0-415c638

Browser and version

Any

Can you reproduce the bug on the Vikunja demo site?

No

Screenshots

No response

[kolaente]

I've set service.publicurl to the full URL used to access Vikunja in the browser (no /api/v1)

That should set the api url accordingly. Can you check what you get if you're viewing the source html of your Vikunja installation in a private tab?

[ozuzo]

With a private window I also get

window.API_URL = 'http://localhost:3456/api/v1'

I was wondering if the cause could be that I use RewriteRule, and not ProxyPass/ProxyPassReverse(as mod_rewrite is available on the shared server, mod_proxy is not)?

[kolaente]

That's odd, it should have set the api URL if you set the public URL. How did you set the config variable? What do you see as frontend_url when you access /api/v1/info in a browser?

[ozuzo]

I see the correct URL in the API output...

Fragment from config.yml:

[kolaente]

Very odd.

I was wondering if the cause could be that I use RewriteRule, and not ProxyPass/ProxyPassReverse(as mod_rewrite is available on the shared server, mod_proxy is not)?

Maybe? I don't know enough about Apache to be sure but if it rewrites content as well, maybe that's the cause?

Does it work if you access Vikunja directly? (Curl on the same server to the port exposed by vikunja should work)

[ozuzo]

With curl, I get the localhost URL in the HTML when requesting the official URL, but the one in config when requesting localhost:3456, so it points in that direction. However, me trying to be clever, I set publicurl to "/" (as the previous versions before .23 just had "/api/v1" as API_URL). Now localhost gives indeed "/api/v1" in the generated HTML, but requesting it via Apache still shows the full localhost one?

Somehow I find it improbable that Apache knows how to/does rewrite

window.API_URL = '/api/v1'

into

window.API_URL = 'http://localhost:3456/api/v1'

in the HTML returned?

[kolaente]

With curl, I get the localhost URL in the HTML when requesting the official URL, but the one in config when requesting localhost:3456

Aren't the two served by the Vikunja binary? Do you see a log entry for each request in Vikunja's logs?

However, me trying to be clever, I set publicurl to "/" (as the previous versions before .23 just had "/api/v1" as API_URL).

You should set that to the full url where Vikunja is reachable, as the publicurl is also used in emails.

[ozuzo]

With "official" URL I meant the "external" URL which is being proxied to port 3456. So that one shows the wrong API_URL, whereas going directly to the binary generates the correct URL (the one in the config). I know about the emails (which we don't use BTW), but I mainly tried that to see if Apache might be rewriting something when proxying. Which I now doubt, as I don't think somethng like '/api/v1' in a HTML file is being rewritten to include the localhost:3456 part...

[kolaente]

Well I don't know enough about Apache to be sure. Vikunja will only ever set the url to what you configured as publicurl + /api/v1 suffix.

[ozuzo]

Neither do I :-) But after some Googling I think I've found a workaround, an Apache directive which substitutes localhost:3456 back to what it should be.