Scott Small 🇨🇦<p>I’m doing some preliminary investigation into the <a href="https://oldbytes.space/tags/Macstodon" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Macstodon</span></a> login issue on Mastodon 4.3. I haven't found the specific cause of the problem, but the error message (“Security verification failed, are you blocking cookies?") seems to imply a CSRF failure.</p><p>I'm not entirely sure why the vintage Mac web browsers I've tried are unable to satisfy this requirement - maybe WebOne is mangling the CSRF cookie, I have to do more testing here.</p><p>One approach to solving this problem would be to use the "password” OAuth grant type, rather than the "authorization_code” grant type that is currently being used. Basically, you would log in to Macstodon with your Mastodon username/password directly, instead of using a web browser. This is the same approach that is currently being used by <a href="https://oldbytes.space/tags/DOStodon" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>DOStodon</span></a> (<a href="https://github.com/SuperIlu/DOStodon/blob/main/mstdn.js#L220" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">github.com/SuperIlu/DOStodon/b</span><span class="invisible">lob/main/mstdn.js#L220</span></a>) and some other retro clients.</p><p>However, there are two problems with using the "password” grant type:</p><p>1. Not all servers support it. For example, compare the outputs of <a href="https://mastodon.social/.well-known/oauth-authorization-server" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">mastodon.social/.well-known/oa</span><span class="invisible">uth-authorization-server</span></a> and <a href="https://urusai.social/.well-known/oauth-authorization-server" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">urusai.social/.well-known/oaut</span><span class="invisible">h-authorization-server</span></a> - and note that mastodon.social lists "password" under "grant_types_supported”, but urusai.social does not (also, that endpoint doesn't exist prior to Mastodon 4.3, so if the server is running an older version you just have to perform trial and error to see if password grants are supported)</p><p>2. MFA is not supported. If you're using multi-factor authentication with your Mastodon account, your only option is to log in using the "authorization_code" grant type. There is no option for appending your MFA token to your password.</p><p>The other option is to use a hybrid approach, where Macstodon would continue to use the "authorization_code" grant type, but would prompt for a username and password as if it were using the "password" grant type. Rather than launching a web browser, it would make the request for the login page directly, fill in the user's credentials and post the form, then screen-scrape the result for the authentication code. This is the approach currently being taken by <a href="https://oldbytes.space/tags/MastAppleII" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>MastAppleII</span></a> (<a href="https://github.com/colinleroy/a2tools/blob/master/src/mastodon/api/oauth.c#L14" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">github.com/colinleroy/a2tools/</span><span class="invisible">blob/master/src/mastodon/api/oauth.c#L14</span></a>).</p><p>This approach is more brittle, and a much more challenging development effort, but it should work with most servers as well as for users with MFA.</p><p>Of course, this approach has one big gotcha of its own - older and newer Mastodon versions are less likely to work correctly due to changes in the design of the login page. Perhaps the "password" grant type should still be offered as an option (if the server supports it), and we allow the user to choose how they want to log in? Or would that be too confusing for users? Alternatively we could try the hybrid approach first, and then fall back to the password grant type if that fails.</p><p>Anyway, I'd love to hear your thoughts on how to approach this!</p><p>RE: <a href="https://oldbytes.space/@smallsco/113312004593805017" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">oldbytes.space/@smallsco/11331</span><span class="invisible">2004593805017</span></a></p><p><a href="https://oldbytes.space/tags/RetroComputing" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>RetroComputing</span></a> <a href="https://oldbytes.space/tags/RetroProgramming" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>RetroProgramming</span></a> <a href="https://oldbytes.space/tags/VintageMac" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>VintageMac</span></a> <a href="https://oldbytes.space/tags/68K" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>68K</span></a> <a href="https://oldbytes.space/tags/PowerPC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>PowerPC</span></a> <a href="https://oldbytes.space/tags/Apple" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Apple</span></a> <a href="https://oldbytes.space/tags/Mac" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Mac</span></a> <a href="https://oldbytes.space/tags/MacOS" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>MacOS</span></a> <a href="https://oldbytes.space/tags/ClassicMac" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>ClassicMac</span></a></p>