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

[eduarrrd]

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

[zero-thermo]

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

[davidmehren]

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.

[kolaente]

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]

Looks like this is actually a spec change: mdn/content#22533

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

[kolaente]

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

[kolaente]

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

[kolaente]

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?

[kolaente]

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

[zero-thermo]

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.