mastodon.social login flaky due to Mastodon OAuth URL handling bug

[fluffy-critter]

I crosspost my posts to both mastodon.social and plush.city. Recently I realized that I never got around to connecting brid.gy to my plush.city account, and when I went to add it, it looks like mastodon.social's connection had disappeared. After successfully adding plush.city, I went to add mastodon.social, and got a 502 error on the OAuth callback:

It isn't clear whether this is due to it trying to reuse the plush.city client/secret/etc. on mastodon.social or if mastodon.social is just plain broken.

[snarfed]

Hey fluffy, sorry for the trouble! I see your OAuth requests for both sites, and Bridgy redirected the same way to both of their OAuth endpoints (below), so I'm not sure why mastodon.social is happy.

• https://plush.city/oauth/authorize?response_type=code&client_id=...&client_secret=...&scope=read:accounts read:blocks read:notifications read:search read:statuses&redirect_uri=https%3A%2F%2Fbrid.gy%2Fmastodon%2Fcallback&state={"app_key":"...","state":"..."}"
• https://mastodon.social/oauth/authorize?response_type=code&client_id=...&client_secret=...&scope=read:accounts read:blocks read:notifications read:search read:statuses&redirect_uri=https%3A%2F%2Fbrid.gy%2Fmastodon%2Fcallback&state={"app_key":"...","state":"..."}"

https://mastodon.social/api/v1/instance says it's v3.4.1, and https://plush.city/api/v1/instance says it's v3.4.3, so this could be a bug in 3.4.1, but seems doubtful.

[snarfed]

I tried the app based OAuth flow with Bridgy's app for each site, and they both gave me an access token and responded fine to /api/v1/apps/verify_credentials. So, no clue what's up with mastodon.social's user OAuth flow 🤷

If it's any consolation, your mastodon.social account was evidently already on Bridgy, and it seems to be working fine: https://brid.gy/mastodon/@fluffy@mastodon.social

[fluffy-critter]

Good to know! Maybe there's something weird with the existing connection information for the brid.gy connection to m.s. But as long as it's still working I'm not too worried.

[snarfed]

I just realized this is probably mastodon/mastodon#12915. Reproducible 502 in Mastodon's OAuth flow due to URL length, narrowed down pretty conclusively in that issue, but they haven't really shown any interest yet. 🤷

[syrabo]

I can not thereby the backfeeding responses set to disable on brid.gy

[snarfed]

@syrabo ugh, sorry for the trouble! That's bad. Short term, I'm happy to disable your Bridgy account manually if you want, just post (or send me) your Bridgy user page URL.

[syrabo]

Thank you for the answer!

Thanks for the help.

I have now tried it again with another browser: Safari. In Safari it worked. The click on disable redirected to mastodon.social to accept bridgy.

I currently work primarily with the Brave browser. Maybe Brave is blocking something here.

Now it is solved. Thanks a lot!

[snarfed]

Oh wow, interesting data point. I assumed it wasn't browser-specific since the Mastodon instance itself returns an HTTP 502, but something else may be going on. Thanks for the tip!

[snarfed]

@metbril, got your email, and saw your mastodon/mastodon#12915 (comment). Sorry for the trouble! Here on GitHub issues is definitely right place to get Bridgy support.

Just to confirm, when you click the pause button on https://brid.gy/mastodon/@metbril@mastodon.social or otherwise try to log into Mastodon on Bridgy, you get the same We're sorry, but something went wrong on our end. error from Mastodon, right?

If so, that is indeed this Mastodon bug, mastodon/mastodon#12915, which we haven't had any luck getting them to pay any attention to. ☹️

Out of curiosity, if you're on a Mac, could you try in Safari and see if it still happens there?

[metbril]

I'v tried on Mac with both Safari, Firefox and Brave with the same result: error 5xx. Brave asks if I want to get the page from The Internet Archive. ;-)

The thing is, that this was working properly until yesterday. I've had some messages back and forth last night (CET). This morning there was some downtime with mastodon.social (around 5:00-5:30 GMT). My mastodon client did weird things. After the server was up, I had a look at Bridgy and noticed the issue.

My guess is that @Gargron did an upgrade, but I didn't get that confirmed. The instance now is at version 3.4.6.

https://mastodon.social/@Mastodon/107718287079955422

Do you have any clue why this issue arose overnight?

[snarfed]

Yeah, it's unfortunate. The bug is only in Mastodon's user-facing OAuth flow. Bridgy holds long-lived access tokens for Mastodon users who have logged in successfully, so it can use those for a long time. If they're ever invalidated, though, eg maybe due to this mastodon.social downtime or upgrade, you need to log into Mastodon again on Bridgy. That's what's failing here.

[snarfed]

@metbril I did some surgery and managed to get your account working with the old Mastodon access token. The underlying Mastodon bug here is still a problem, but glad at least you're back up and running.

[metbril]

@metbril I did some surgery and managed to get your account working with the old Mastodon access token. The underlying Mastodon bug here is still a problem, but glad at least you're back up and running.

Unfortunately, this morning I noticed that yellow paused button on my page again: https://brid.gy/mastodon/@metbril@mastodon.social

Is there any way I / your / we can get and keep backfeeding and posse-ing alive @snarfed ?

(Apart from changing instance, that is 😉)

[snarfed]

Hi again @metbril! I've re-enabled backfeed for your account. Looks like your Bridgy Mastodon OAuth token doesn't include the publish scopes, though, which is why Bridgy was disabling the account. I've turned off that part. Once this Mastodon bug is fixed, you should be able to enable it again!

[snarfed]

Discussion is now in doorkeeper-gem/doorkeeper#1554, tentative conclusion is that the issue is in doorkeeper. Still not much more movement though. 😐

[snarfed]

Merging into #911, same root cause.