Mastodon API: support form data for parameters

[GeopJr]

💡 Summary

Mastodon accepts 3 different ways for providing parameters:

• Query strings
• Form data
• JSON

https://docs.joinmastodon.org/client/intro/#parameters

Sharkey seems to accept at least JSON but not form data preventing some clients from working. see: https://github.com/GeopJr/Tuba/issues/643

🥰 Expected Behavior

Sharkey should accept form data and the client should register successfully, like so:

$ curl -X POST -F 'client_name=Example' -F 'redirect_uris=urn:ietf:wg:oauth:2.0:oob' -F 'scopes=read' -F 'website=https://example.com/' https://mastodon.social/api/v1/apps
{"id":"4946108","name":"Example","website":"https://example.com/","redirect_uri":"urn:ietf:wg:oauth:2.0:oob","client_id":"y-yEO3kmUCQKmHXZwm04QlINfpWXvhKHqQLxSt2dTKI","client_secret":"_fvTRtNG6-73lR6phv2wqnm-vGYzMu5Fp0oUgeuaquM","vapid_key":"BCk-QqERU0q-CfYZjcuB6lnyyOYfJ2AifKqfeGIm7Z-HiTU5T9eTG5GxVA0_OH5mMlI4UkkDTpaZwozy0TzdZ2M="}

🤬 Actual Behavior

The client receives

{"statusCode":401,"error":"Unauthorized","message":"Cannot read properties of undefined (reading 'data')"}

📝 Steps to Reproduce

1. curl -X POST -F 'client_name=Example' -F 'redirect_uris=urn:ietf:wg:oauth:2.0:oob' -F 'scopes=read' -F 'website=https://example.com/' https://transfem.social/api/v1/apps

💻 Frontend Environment

No response

🛰 Backend Environment (for server admin)

No response

[Mar0xy]

Thanks for the hint that it was due to missing Form Data acceptance this generally is happening due to the fact that Fastify the router misskey uses and so also the mastodon api does not accept anything but JSON and Query Strings ootb the form data acceptance on some endpoints had to be manually created by adding a new handler.

I will look into fixing it later.

[GeopJr]

I vaguely remember fixing it for Calckey (before Firefish) ages ago but with all the repo migrations I can't find it. Though it used Koa so it doesn't matter anyway

[Mar0xy]

Eh, It is easy to fix in the first place since the update_credentials endpoints and a few other sections use form data already I mostly based the work on the Mastodon API off web clients and mobile clients which all use JSON to submit data.

[Mar0xy]

I have now managed to login but it seems like Tuba doesn't know how to handle up to date misskey image URLs since Misskey primarily uses WEBP or Gif(for animated pfps).

[GeopJr]

You need webp-pixbuf-loader for webp support

If it managed to pass the new account window then everything else should work as expected!

[GeopJr]

Actually, I'll list on what other endpoints we use form data, I'm not sure about other clients:

• /api/v1/markers
• /api/v1/accounts/update_credentials
• /api/v1/statuses/:id/reblog

Looking at the commit, if possible, I'd enable it to all endpoints that accept parameters. We used to also use it for creating statuses but later switched to json.

[Mar0xy]

/api/v1/markers doesn't exist on our end as there is no real function for it on misskey /api/v1/accounts/update_credentials already uses it as that is the only type it can really use due to files /api/v1/statuses/:id/reblog I actually tried reblogging out and it worked fine

[GeopJr]

I actually tried reblogging out and it worked fine

on main you can choose boost visibility which uses form data

doesn't exist on our end as there is no real function for it on misskey

we use it to check unread notifications and for marking notifications as read

[Mar0xy]

we use it to check unread notifications and for marking notifications as read

That's the thing misskey uses redis mostly for notifications so there are no endpoints for seeing unread notifications there is only a general one for viewing all which obviously does exist and automatically marks all notifications as read.

on main you can choose boost visibility which uses form data

This can also be mostly ignored cause in case of misskey you can only reblog publicly there is no private or non-private system for reblogs nor is there any system in the backend package that handles the api stuff for mastodon outside of our code.

[GeopJr]

Sounds good to me for both! (Tuba doesn't do this) but if a client checks for unread notifications manually every n seconds, users might receive constant errors if sharkey returns 4xx

Either way, I think this issue is done so I'll close it. Thanks for taking care of it so fast!