[Bug]: Unauthorized, token not supplied

[daenney]

Describe the bug

After upgrading to 0.6.1 I get "unauthorized, token not supplied" errors when clicking on any username @mention in a post/toot.

I signed out and back into my account, but the issue persists.

Steps To Reproduce

1. Load timeline
2. Click on an @mention
3. Get a little pop-over in the bottom

Logs and/or Screenshots

(dev.geopjr.Tuba:2): Tuba-DEBUG: 17:03:57.512: Network.vala:59: GET: https://ap.dny.social/api/v1/accounts/<REDACTED>

(dev.geopjr.Tuba:2): Tuba-WARNING **: 17:03:57.581: Network.vala:100: Unauthorized: token not supplied

Instance Backend

GoToSocial

Operating System

Arch Linux

Package

Flatpak

Troubleshooting information

os: GNOME 45 (Flatpak runtime)
prefix: /app
flatpak: true
version: 0.6.1 (production)
gtk: 4.12.4 (4.12.4)
libadwaita: 1.4.2 (1.4.2)
libsoup: 3.4.4 (3.4.4)
libgtksourceview: 5.10.0 (5.10.0)

Additional Context

No response

[daenney]

My guess is this happened in 0.6.0, not 0.6.1 since that only included a translation fix. Just hadn't upgraded yet. It definitely worked fine on 0.5.

[GeopJr]

Nice catch! So, this is happening due to this: https://github.com/GeopJr/Tuba/commit/ede5556a021feed59b259b75ac3027fbf457d201

Since Tootle/before Tuba, when a mention was clicked, it would first check if it's included in the "mentions" field of the status and try to open the account from the ID, otherwise go through the rest of the resolving process (which ends with a request to the instance's search api). That never worked due to the typo that the linked commit fixed.

API wise, it does an unauthorized request to the active account's /api/v1/accounts/$id. It doesn't seem to require the token on mastodon even with auth_fetch (https://tech.lgbt/api/v1/accounts/109242) but it also wouldn't hurt to provide it either

What do you think would be the best solution?

1. Ask GoToSocial to make it unauthorized
2. Tuba provides the token
3. Remove the whole mention checking thing and just let resolving figure it out

I'm mostly leaning towards the second option. GoToSocial requiring auth for it sounds reasonable (even if it was unintentional) and going straight to resolving when we could save some time by opening it manually doesn't seem that appropriate

[daenney]

As I'm one of the GoToSocial developers, we tend to not make API endpoints like these public as they can easily be used for data scraping and other stuff.

I haven't ran into this with other clients I use but I'm not sure which approach they take. Looking at the Masto API documentation, it does seem like providing an Authorization header with the token is a supported thing for Get account, and it does document a possible unauthorized response if it is missing in case authentication is required for the endpoint.

Based on that, I would be inclined to change it to include the token in the request.

[daenney]

The one bit of the docs that has me a bit confused, is that in the 401 unauthorized response it says this can happen if the instance is in whitelist mode. I believe what they mean by that is authorized fetch, but I'm not 100% sure. That would contradict what you found in testing though, so that's rather interesting.

[GeopJr]

I'll fix this as soon as possible, thanks!

I wonder if something changed since tootle added it 6 years ago and why it was made unauthorized to begin with. Some endpoints on mastodon's docs are definitely copy-pasted / from a template and don't actually match the actual implementation :shrug:

[daenney]

Yap, we've noticed that. It's hard to know how the API actually behaves from the docs. It's super frustrating and figuring out from code isn't always easy if you don't have a passing familiarity with Ruby and RoR.