Mastodon: Repeated "401 The access token is invalid" errors for "Home" and "Notifications" streams in Safari

[davidcelis]

When I sign into my Mastodon instance in Safari, I'm greeted with a pair of 401 The access token is invalid error pop-ups that appear repeatedly (every time a refresh of the Home and Notifications columns is attempted). It doesn't appear to happen in Chrome, but I don't want to use Chrome.

I'm able to view the public timeline, of course, but am unable to view my personal feed or notifications. I've tried clearing my cookies and signing back in, but this always happens to me.

---

• [x] I searched or browsed the repo’s other issues to ensure this is not a duplicate.

[wxcafe]

What version are you running? Can you post logs, a browser console screenshot with errors, something?

[davidcelis]

We're sitting at commit 93db265be7b648fe095d5a92b76c5c7077c72ac2 until the fix for the notifications tab is merged (#1491)

The request (copied as cURL) is:

curl 'https://xoxo.zone/api/v1/timelines/home' \
-X GET \
-H 'DNT: 1' \
-H 'Referer: https://xoxo.zone/web/getting-started' \
-H 'Authorization: Bearer <snip>' \
-H 'Accept: application/json, text/plain, */*' \
-H 'Cache-Control: max-age=0' \
-H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/603.1.30 (KHTML, like Gecko) Version/10.1 Safari/603.1.30'

And the response comes through as:

I also made sure that the bearer token listed in the request actually exists in the database and is associated with my account, and both of these things are true.

Unfortunately, my instance doesn't seem to be logging anywhere. nginx has access logs, but log/production.log is simply empty. I don't know why.

[wxcafe]

Well, the fix for the notifications tab is fixed :) Could you try upgrading and see if you still have that issue? If you're not using docker and are using the provided systemd .service files, you can access the logs by using journalctl -u mastodon-whatever

[davidcelis]

I still get a 401 for both the local timeline _and_ the notifications tab. I believe this is different than the previous issue with the notifications tab that was fixed. All I get from journalctl -u mastodon-web is a basic access log, it seems:

Apr 14 16:23:37 xoxo bundle[9812]: [32bb6b4d-133b-4789-9a96-afe08f773a37] method=GET path=/api/v1/timelines/home format=html controller=Api::V1::TimelinesController action=home status=401 duration=4.91 view=0.20 db=0.84
Apr 14 16:23:37 xoxo bundle[9812]: [1783b83f-14a7-4915-b0cf-df96194cdb70] method=GET path=/api/v1/notifications format=html controller=Api::V1::NotificationsController action=index status=401 duration=20.84 view=0.23 db=0.69

[davidcelis]

I could really use some help with this issue. I'm the admin of my instance, so having any API request while I'm logged in return a 401 is not ideal. Thanks!

[vincentux]

Maybe a solution here https://github.com/YunoHost-Apps/mastodon_ynh/issues/5

[davidcelis]

@vincentux Thanks, unfortunately I didn't find anything there that would have helped me 😞 I don't have a line like access_by_lua_file /usr/share/ssowat/access.lua; in my nginx config.

[davidcelis]

UPDATE: This appears to only happen in Safari; Chrome works fine, but I use Safari for everything else so I'd still like to see this fixed.

@Gargron Sorry to ping you directly, but I just don't know what to do at this point. I've tried so far as to completely delete my User/Account and sign up with a new one. I immediately begin by getting 401s for the Notifications and Local Timeline streams. What's weird about this is that I can copy the request from Safari's network inspector to a cURL request, and it _works totally fine_. The _exact same request_. I don't know what's up with that.

Here's the Safari request:

$ curl 'https://xoxo.zone/api/v1/notifications' \
                                    -XGET \
                                    -H 'DNT: 1' \
                                    -H 'Referer: https://xoxo.zone/web/getting-started' \
                                    -H 'Authorization: Bearer $MASTODON_TOKEN' \
                                    -H 'Accept: application/json, text/plain, */*' \
                                    -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/603.1.30 (KHTML, like Gecko) Version/10.1 Safari/603.1.30' --include
HTTP/1.1 200 OK
Date: Thu, 27 Apr 2017 17:00:24 GMT
Content-Type: application/json; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Server: Mastodon
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
X-RateLimit-Limit: 300
X-RateLimit-Remaining: 298
X-RateLimit-Reset: 2017-04-27T17:05:00.307923Z
Vary: Accept-Encoding, Origin
ETag: W/"4f53cda18c2baa0c0354bb5f9a3ecbe5"
Cache-Control: max-age=0, private, must-revalidate
X-Request-Id: 37234dca-7a34-4434-a43c-38b033463a98
X-Runtime: 0.012949
Strict-Transport-Security: max-age=63072000; includeSubdomains
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000; includeSubDomains

[]

401 when performed by Safari itself, but works fine as a cURL request in Terminal.app. For posterity, here's the same request when performed by Chrome:

curl 'https://xoxo.zone/api/v1/notifications' -H 'Cookie: $MASTODON_COOKIE' -H 'Accept-Encoding: gzip, deflate, sdch, br' -H 'Accept-Language: en-US,en;q=0.8' -H 'Authorization: Bearer $MASTODON_TOKEN' -H 'Accept: application/json, text/plain, */*' -H 'Referer: https://xoxo.zone/web/accounts/6494' -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.81 Safari/537.36' -H 'If-None-Match: W/"d0bfaca067f072e3030812d58b26302d"' -H 'Connection: keep-alive' --compressed --include
HTTP/1.1 200 OK
Date: Thu, 27 Apr 2017 17:00:07 GMT
Content-Type: application/json; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Server: Mastodon
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
X-RateLimit-Limit: 300
X-RateLimit-Remaining: 299
X-RateLimit-Reset: 2017-04-27T17:05:00.969149Z
Vary: Accept-Encoding, Origin
Content-Encoding: gzip
ETag: W/"eb45a3983b105ed7aeaf9dab5a4b138a"
Cache-Control: max-age=0, private, must-revalidate
X-Request-Id: 8acf6bf0-4a83-460a-a73d-e11d56678f3b
X-Runtime: 0.011634
Strict-Transport-Security: max-age=63072000; includeSubdomains
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000; includeSubDomains

[]

Safari and Chrome are using different access tokens, but I verified that both access tokens exist and belong to me using a production rails console.

[Gargron]

I would like to close old issues. This seems like a very mystical issue that no one else is having right now.

[davidcelis]

That's a shame. It means I have to give up on Mastodon and managing the instance I'm an admin of.

[Gargron]

@davidcelis

You could just reopen if you disagree, no need to drop ultimatums.

There's been a couple releases since the issue was opened. You said that the exact same HTTP request, performed via cURL, results in no errors, likewise for Chrome. Nobody else seems to have had this issue. The last activity on this issue was a month before I now decided to close it. I don't know what I could do here. I don't even have access to Safari, since that browser is locked in to an expensive platform I don't own.