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

[GH-ISSUE #146] JWT not sent to API after login on Firefox 111 in HTTPS-only mode #5926

New Issue
Closed
opened 2026-04-20 16:22:54 -05:00 by GiteaMirror · 9 comments
GiteaMirror commented 2026-04-20 16:22:54 -05:00
Owner
Copy Link

Originally created by @eduarrrd on GitHub (Mar 19, 2023).
Original GitHub issue: https://github.com/go-vikunja/vikunja/issues/146

Description

Vikunja does not allow me to log in using Firefox 111 (possibly earlier) using the HTTPS-only mode. Disabling the HTTPS-only mode causes login to succeed. It appears that it can be re-enabled afterwards and things keep working but I did not investigate.

It works in Chrome 112 with Chrome's default config.

The following is gathered using the Firefox Devtools.

Login succeeds:
Request

POST /api/v1/login HTTP/2
Host: try.vikunja.io
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/111.0
Accept: application/json, text/plain, */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Content-Type: application/json
Content-Length: 56
Origin: https://try.vikunja.io
DNT: 1
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
TE: trailers

{"username":"demo","password":"demo","long_token":false}

gets response

HTTP/2 200 OK
access-control-allow-origin: *
content-type: application/json; charset=UTF-8
date: Sun, 19 Mar 2023 16:08:43 GMT
permissions-policy: interest-cohort=()
vary: Origin
x-ratelimit-limit: 10
x-ratelimit-remaining: 8
x-ratelimit-reset: 1679242138
content-length: 274
X-Firefox-Spdy: h2

{"token":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJlbWFpbCI6IiIsImVtYWlsUmVtaW5kZXJzRW5hYmxlZCI6ZmFsc2UsImV4cCI6MTY4MTgzMjE1MywiaWQiOjEsImlzTG9jYWxVc2VyIjp0cnVlLCJsb25nIjp0cnVlLCJuYW1lIjoiRWR1YXJkIiwidHlwZSI6MSwidXNlcm5hbWUiOiJlIn0.jU-lg26liptXhtw1Kun2O2lCthGqxTbTFZGKYhu7jjo"}

However, the subsequent call to /api/v1/user doesn't supply the JWT:

GET /api/v1/user HTTP/2
Host: try.vikunja.io
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/111.0
Accept: application/json, text/plain, */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Origin: https://try.vikunja.io
DNT: 1
Connection: keep-alive
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
TE: trailers

resulting in a 401 response:

HTTP/2 401 Unauthorized
access-control-allow-origin: *
content-type: application/json; charset=UTF-8
date: Sun, 19 Mar 2023 15:40:11 GMT
permissions-policy: interest-cohort=()
vary: Origin
content-length: 39
X-Firefox-Spdy: h2

{"message":"missing or malformed jwt"}

In the js console I see the following relevant lines:

Vikunja frontend version 0.20.5+45-846de369f2 [index-7233cea9.js:817:112651](https://try.vikunja.io/assets/index-7233cea9.js)
HTTPS-Only Mode: Upgrading insecure request “http://try.vikunja.io/api/v1/info” to use “https”.
HTTPS-Only Mode: Upgrading insecure request “http://try.vikunja.io/api/v1/user” to use “https”.

Vikunja Frontend Version

0.20.5+45-846de369f2

Vikunja API Version

Whatever try.vikunja.org is using at the time of this post.

Browser and version

Firefox 111

Can you reproduce the bug on the Vikunja demo site?

Yes

Screenshots

No response

Originally created by @eduarrrd on GitHub (Mar 19, 2023). Original GitHub issue: https://github.com/go-vikunja/vikunja/issues/146 ### Description Vikunja does not allow me to log in using Firefox 111 (possibly earlier) using the HTTPS-only mode. Disabling the HTTPS-only mode causes login to succeed. It appears that it can be re-enabled afterwards and things keep working but I did not investigate. It works in Chrome 112 with Chrome's default config. The following is gathered using the Firefox Devtools. Login succeeds: Request ``` POST /api/v1/login HTTP/2 Host: try.vikunja.io User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/111.0 Accept: application/json, text/plain, */* Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate, br Content-Type: application/json Content-Length: 56 Origin: https://try.vikunja.io DNT: 1 Sec-Fetch-Dest: empty Sec-Fetch-Mode: cors Sec-Fetch-Site: same-origin Connection: keep-alive Pragma: no-cache Cache-Control: no-cache TE: trailers {"username":"demo","password":"demo","long_token":false} ``` gets response ``` HTTP/2 200 OK access-control-allow-origin: * content-type: application/json; charset=UTF-8 date: Sun, 19 Mar 2023 16:08:43 GMT permissions-policy: interest-cohort=() vary: Origin x-ratelimit-limit: 10 x-ratelimit-remaining: 8 x-ratelimit-reset: 1679242138 content-length: 274 X-Firefox-Spdy: h2 {"token":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJlbWFpbCI6IiIsImVtYWlsUmVtaW5kZXJzRW5hYmxlZCI6ZmFsc2UsImV4cCI6MTY4MTgzMjE1MywiaWQiOjEsImlzTG9jYWxVc2VyIjp0cnVlLCJsb25nIjp0cnVlLCJuYW1lIjoiRWR1YXJkIiwidHlwZSI6MSwidXNlcm5hbWUiOiJlIn0.jU-lg26liptXhtw1Kun2O2lCthGqxTbTFZGKYhu7jjo"} ``` However, the subsequent call to `/api/v1/user` doesn't supply the JWT: ``` GET /api/v1/user HTTP/2 Host: try.vikunja.io User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/111.0 Accept: application/json, text/plain, */* Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate, br Origin: https://try.vikunja.io DNT: 1 Connection: keep-alive Sec-Fetch-Dest: empty Sec-Fetch-Mode: cors Sec-Fetch-Site: same-origin TE: trailers ``` resulting in a 401 response: ``` HTTP/2 401 Unauthorized access-control-allow-origin: * content-type: application/json; charset=UTF-8 date: Sun, 19 Mar 2023 15:40:11 GMT permissions-policy: interest-cohort=() vary: Origin content-length: 39 X-Firefox-Spdy: h2 {"message":"missing or malformed jwt"} ``` In the js console I see the following relevant lines: ``` Vikunja frontend version 0.20.5+45-846de369f2 [index-7233cea9.js:817:112651](https://try.vikunja.io/assets/index-7233cea9.js) HTTPS-Only Mode: Upgrading insecure request “http://try.vikunja.io/api/v1/info” to use “https”. HTTPS-Only Mode: Upgrading insecure request “http://try.vikunja.io/api/v1/user” to use “https”. ``` ### Vikunja Frontend Version 0.20.5+45-846de369f2 ### Vikunja API Version Whatever try.vikunja.org is using at the time of this post. ### Browser and version Firefox 111 ### Can you reproduce the bug on the Vikunja demo site? Yes ### Screenshots _No response_
GiteaMirror added the questionbug labels 2026-04-20 16:22:54 -05:00
GiteaMirror commented 2026-04-20 16:22:57 -05:00
Author
Owner
Copy Link

@zero-thermo commented on GitHub (Mar 20, 2023):

I am also ran into a similar issue, and lost access to Vikunja via https://vikunja.tld after upgrading to Firefox 111. I'm using a docker-compose setup with Nginx Proxy Manager.

I was able to restore access to my data with these Nginx Proxy Manager configs

Despite restoring access, https://vikunja.tld/api/v1/ now displays this message:

missing or malformed jwt
<!-- gh-comment-id:1934163085 --> @zero-thermo commented on GitHub (Mar 20, 2023): I am also ran into a similar issue, and lost access to Vikunja via https://vikunja.tld after upgrading to Firefox 111. I'm using a docker-compose setup with Nginx Proxy Manager. I was able to restore access to my data with these [Nginx Proxy Manager configs](https://github.com/NginxProxyManager/nginx-proxy-manager/discussions/1522#discussioncomment-1539670) Despite restoring access, https://vikunja.tld/api/v1/ now displays this message: missing or malformed jwt
GiteaMirror commented 2026-04-20 16:22:58 -05:00
Author
Owner
Copy Link

@davidmehren commented on GitHub (Mar 20, 2023):

The Firefox 111 release notes say:

The HTTP Authorization header is removed from fetch() and XMLHttpRequest requests that are redirected cross-origin (fetch() headers may be added by developers using the option.headers argument). See Firefox bug 1802086 for more details.

That sounds like it could be related.

<!-- gh-comment-id:1934163102 --> @davidmehren commented on GitHub (Mar 20, 2023): The [Firefox 111 release notes](https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/111) say: > The HTTP [Authorization](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization) header is removed from [fetch()](https://developer.mozilla.org/en-US/docs/Web/API/fetch) and [XMLHttpRequest](https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest) requests that are redirected cross-origin (fetch() headers may be added by developers using the [option.headers](https://developer.mozilla.org/en-US/docs/Web/API/fetch#headers) argument). See [Firefox bug 1802086](https://bugzil.la/1802086) for more details. That sounds like it could be related.
GiteaMirror commented 2026-04-20 16:22:58 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Mar 20, 2023):

The Firefox 111 release notes say:

The HTTP Authorization header is removed from fetch() and XMLHttpRequest requests that are redirected cross-origin (fetch() headers may be added by developers using the option.headers argument). See Firefox bug 1802086 for more details.

That sounds like it could be related.

This does sound like it might be the cause here. On try the api request is not a cross-origin one though. Not sure what to make of this.

<!-- gh-comment-id:1934163106 --> @kolaente commented on GitHub (Mar 20, 2023): > The [Firefox 111 release notes](https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/111) say: > > > The HTTP [Authorization](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization) header is removed from [fetch()](https://developer.mozilla.org/en-US/docs/Web/API/fetch) and [XMLHttpRequest](https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest) requests that are redirected cross-origin (fetch() headers may be added by developers using the [option.headers](https://developer.mozilla.org/en-US/docs/Web/API/fetch#headers) argument). See [Firefox bug 1802086](https://bugzil.la/1802086) for more details. > > That sounds like it could be related. This does sound like it might be the cause here. On try the api request is not a cross-origin one though. Not sure what to make of this.
GiteaMirror commented 2026-04-20 16:22:59 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Mar 20, 2023):

Looks like this is actually a spec change: https://github.com/mdn/content/issues/22533

So it will stop working in Chrome as well once they include the spec update.

<!-- gh-comment-id:1934163110 --> @kolaente commented on GitHub (Mar 20, 2023): Looks like this is actually a spec change: https://github.com/mdn/content/issues/22533 So it will stop working in Chrome as well once they include the spec update.
GiteaMirror commented 2026-04-20 16:22:59 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Mar 20, 2023):

I just tested this in Firefox Dev 112 and it seems to work fine. Can anyone else confirm this?

<!-- gh-comment-id:1934163113 --> @kolaente commented on GitHub (Mar 20, 2023): I just tested this in Firefox Dev 112 and it seems to work fine. Can anyone else confirm this?
GiteaMirror commented 2026-04-20 16:23:00 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Mar 20, 2023):

Now also tested in Firefox 111 and it seems to work there as well. (Both on my NixOS)

<!-- gh-comment-id:1934163117 --> @kolaente commented on GitHub (Mar 20, 2023): Now also tested in Firefox 111 and it seems to work there as well. (Both on my NixOS)
GiteaMirror commented 2026-04-20 16:23:00 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Mar 20, 2023):

Okay so I kind of reproduced it in Firefox dev 112:

  1. Enable HTTPS only mode
  2. Open Vikunja (tested with try)
  3. Reload it a few time (~2-3)
  4. Check in "Storage" > "Local Storage" the value of the API_URL saved there: It probably starts with http instead of https.
  5. Now try to log in
  6. Get the error message

Now, I wonder why it saves http in the first place?

I was able to fix this by explicitely setting the API_URL for the frontend to the full api url including https://.. (tested on try). @eduarrrd @zero-thermo can you check if it works for you on try?

To me, this kind of looks like a bug in Firefox. It seems like other people noticed as well but in that bug report it appears fixed?

<!-- gh-comment-id:1934163121 --> @kolaente commented on GitHub (Mar 20, 2023): Okay so I kind of reproduced it in Firefox dev 112: 1. Enable HTTPS only mode 2. Open Vikunja (tested with try) 3. Reload it a few time (~2-3) 4. Check in "Storage" > "Local Storage" the value of the `API_URL` saved there: It probably starts with `http` instead of `https`. 5. Now try to log in 6. Get the error message Now, I wonder why it saves `http` in the first place? I was able to fix this by explicitely setting the `API_URL` for the frontend to the full api url including `https://..` (tested on try). @eduarrrd @zero-thermo can you check if it works for you on [try](https://try.vikunja.io)? To me, this kind of looks like a bug in Firefox. It seems like [other people noticed as well](https://bugzilla.mozilla.org/show_bug.cgi?id=1817980) but in that bug report it appears fixed?
GiteaMirror commented 2026-04-20 16:23:01 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Mar 20, 2023):

Opened a follow-up bug report to clarify if this has been fixed in Firefox and just not yet released or if it needs a new fix: https://bugzilla.mozilla.org/show_bug.cgi?id=1823502

<!-- gh-comment-id:1934163133 --> @kolaente commented on GitHub (Mar 20, 2023): Opened a follow-up bug report to clarify if this has been fixed in Firefox and just not yet released or if it needs a new fix: https://bugzilla.mozilla.org/show_bug.cgi?id=1823502
GiteaMirror commented 2026-04-20 16:23:01 -05:00
Author
Owner
Copy Link

@zero-thermo commented on GitHub (Mar 21, 2023):

I was able to fix this by explicitely setting the API_URL for the frontend to the full api url including https://.. (tested on try). @eduarrrd @zero-thermo can you check if it works for you on try?

https://try.vikunja.io works, but also displays the same missing or malformed jwt as my own http://vikunja.tld/api/v1 instance. Despite that error message, basic operations seems to be functioning (creating tasks, changing dates, marking as done). Same results whether using http:// or https:// in my VIKUNJA_API_URL and VIKUNJA_SERVICE_FRONTENDURL environment variables.

Thanks for being a responsive developer, and for your continued work on this app.

<!-- gh-comment-id:1934163141 --> @zero-thermo commented on GitHub (Mar 21, 2023): > I was able to fix this by explicitely setting the `API_URL` for the frontend to the full api url including `https://..` (tested on try). @eduarrrd @zero-thermo can you check if it works for you on [try](https://try.vikunja.io)? `https://try.vikunja.io` works, but also displays the same `missing or malformed jwt` as my own `http://vikunja.tld/api/v1` instance. Despite that error message, basic operations seems to be functioning (creating tasks, changing dates, marking as done). Same results whether using `http://` or `https://` in my `VIKUNJA_API_URL` and `VIKUNJA_SERVICE_FRONTENDURL` environment variables. Thanks for being a responsive developer, and for your continued work on this app.
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 bug question
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#5926
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?