JWT not sent to API after login on Firefox 111 in HTTPS-only mode

deekerman commented

2026-02-27 14:53:22 -05:00

Owner

Originally created by @eduarrrd on GitHub (Mar 19, 2023).

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). ### 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_

deekerman

2026-02-27 14:53:22 -05:00

closed this issue
added the
bug

question
labels

deekerman commented

2026-02-27 14:53:28 -05:00

Author

Owner

@zero-thermo commented on GitHub (Mar 19, 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

@zero-thermo commented on GitHub (Mar 19, 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

deekerman commented

2026-02-27 14:53:28 -05:00

Author

Owner

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

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

deekerman commented

2026-02-27 14:53:28 -05:00

Author

Owner

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

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

deekerman commented

2026-02-27 14:53:28 -05:00

Author

Owner

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

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

deekerman commented

2026-02-27 14:53:29 -05:00

Author

Owner

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

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

deekerman commented

2026-02-27 14:53:29 -05:00

Author

Owner

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

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

deekerman commented

2026-02-27 14:53:29 -05:00

Author

Owner

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

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

Enable HTTPS only mode
Open Vikunja (tested with try)
Reload it a few time (~2-3)
Check in "Storage" > "Local Storage" the value of the API_URL saved there: It probably starts with http instead of https.
Now try to log in
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?

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

deekerman commented

2026-02-27 14:53:29 -05:00

Author

Owner

@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

@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

deekerman commented

2026-02-27 14:53:29 -05:00

Author

Owner

@zero-thermo commented on GitHub (Mar 20, 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.

@zero-thermo commented on GitHub (Mar 20, 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.

Rows
Columns

JWT not sent to API after login on Firefox 111 in HTTPS-only mode #130

Description

Vikunja Frontend Version

Vikunja API Version

Browser and version

Can you reproduce the bug on the Vikunja demo site?

Screenshots