github-starred/vikunja
2
0
Fork 0
mirror of https://github.com/go-vikunja/vikunja.git synced 2026-05-30 13:46:39 -05:00
Code Issues 690 Packages Projects Releases 11 Wiki Activity

No more separate frontend, proxy and window.API_URL #1919

New Issue
Closed
opened 2026-03-22 13:46:14 -05:00 by GiteaMirror · 10 comments
GiteaMirror commented 2026-03-22 13:46:14 -05:00
Owner
Copy Link

Originally created by @ozuzo on GitHub (Feb 20, 2024).

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

Originally created by @ozuzo on GitHub (Feb 20, 2024). ### 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_
GiteaMirror commented 2026-03-22 13:46:15 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Feb 20, 2024):

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?

@kolaente commented on GitHub (Feb 20, 2024): > 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?
GiteaMirror commented 2026-03-22 13:46:15 -05:00
Author
Owner
Copy Link

@ozuzo commented on GitHub (Feb 20, 2024):

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)?

@ozuzo commented on GitHub (Feb 20, 2024): 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)?
GiteaMirror commented 2026-03-22 13:46:15 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Feb 20, 2024):

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?

@kolaente commented on GitHub (Feb 20, 2024): 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?
GiteaMirror commented 2026-03-22 13:46:15 -05:00
Author
Owner
Copy Link

@ozuzo commented on GitHub (Feb 21, 2024):

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

Screenshot 2024-02-21 095028

Screenshot 2024-02-21 094941

Fragment from config.yml:

Screenshot 2024-02-21 095229

@ozuzo commented on GitHub (Feb 21, 2024): I see the correct URL in the API output... ![Screenshot 2024-02-21 095028](https://github.com/go-vikunja/vikunja/assets/5175516/489d8dd3-27f7-4aa4-a4e0-e147cb0960e8) ![Screenshot 2024-02-21 094941](https://github.com/go-vikunja/vikunja/assets/5175516/81ada0a1-01bf-4920-9f9e-7f2e2781ecc3) Fragment from config.yml: ![Screenshot 2024-02-21 095229](https://github.com/go-vikunja/vikunja/assets/5175516/7411d2b7-9ba1-4f93-8ea0-14327c4b5f5b)
GiteaMirror commented 2026-03-22 13:46:16 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Feb 21, 2024):

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)

@kolaente commented on GitHub (Feb 21, 2024): 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)
GiteaMirror commented 2026-03-22 13:46:16 -05:00
Author
Owner
Copy Link

@ozuzo commented on GitHub (Feb 21, 2024):

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?

@ozuzo commented on GitHub (Feb 21, 2024): 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?
GiteaMirror commented 2026-03-22 13:46:16 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Feb 25, 2024):

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.

@kolaente commented on GitHub (Feb 25, 2024): > 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.
GiteaMirror commented 2026-03-22 13:46:16 -05:00
Author
Owner
Copy Link

@ozuzo commented on GitHub (Feb 26, 2024):

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...

@ozuzo commented on GitHub (Feb 26, 2024): 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...
GiteaMirror commented 2026-03-22 13:46:17 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Feb 27, 2024):

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.

@kolaente commented on GitHub (Feb 27, 2024): 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.
GiteaMirror commented 2026-03-22 13:46:17 -05:00
Author
Owner
Copy Link

@ozuzo commented on GitHub (Feb 27, 2024):

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.

@ozuzo commented on GitHub (Feb 27, 2024): 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.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area/api
area/attachments
area/auth
area/avatars
area/backup-restore
area/caldav
area/calendar-view
area/comments
area/config
area/database
area/desktop
area/docker
area/email
area/favorites
area/filters
area/frontend
area/gantt
area/i18n
area/import-export
area/internal-code
area/kanban
area/labels
area/list-view
area/mobile
area/notifications
area/permissions
area/projects
area/pwa
area/recurring-tasks
area/reminders
area/search
area/shortcuts
area/subtasks
area/sync
area/table-view
area/task-editor
area/task-metadata
area/task-relations
area/teams
area/theming
area/time-tracking
area/typesense
area/views
area/webhooks
bug
changes requested
concern/accessibility
concern/performance
concern/regression
concern/ux
confirmed
db/mysql
dependencies
enhancement
good first issue
help wanted
integration/inbound
integration/outbound
kind/bug
kind/feature
needs reproduction
pull-request
Mirrored from GitHub Pull Request
 question
security
support
upstream issue
waiting for reply
wontfix
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/vikunja#1919
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?