Closed GeopJr closed 9 months ago
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.
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
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.
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).
You need webp-pixbuf-loader
for webp support
If it managed to pass the new account window then everything else should work as expected!
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.
/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
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
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.
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!
💡 Summary
Mastodon accepts 3 different ways for providing parameters:
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:
🤬 Actual Behavior
The client receives
📝 Steps to Reproduce
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