-
-
Notifications
You must be signed in to change notification settings - Fork 6.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expose the settings API to other clients #3529
Comments
/api/web is a persistence layer for the JavaScript state in the web UI, nothing more. I would have used localStorage if it would be accessed from one device only, but it can be accessed through any, so it had to persist between devices, therefore that internal API. You can't use it with an access token, only a valid session. |
I understand the point of app state persistence, right. I still feel like settings persistence, interoperability and sharing accross devices might be something worth to users, though. No big deal. Just so you know and FWIW, I confirm one can update the settings just using the bearer token, no webapp cookie needed. Here's a sample trace from Insomnia, obfuscated on purpose:
|
You sent a cookie along, are you sure that isn't an authenticated session? If not I think I know what kind of accidental regression may have changed it around to accepting access tokens. That's not a big deal but not intended. |
Yes I'm sure, here's another trace without no cookie passed at all.
Yes that's no big deal. |
I'm one of the developer of Tooty, a Web client for Mastodon. I see on the official client that the
/api/web/settings
endpoint is used to persist settings for notifications, filters and so on, and I'd love using it as well for Tooty, so its users could use the same settings as with the official client.While it seems I can update settings using
PUT /api/web/settings
and a Bearer token, I couldn't find any other place for GETting the settings from the server than/web/getting-started
, which only delivers HTML with a script tag containing the JSON for settings.I'm obviously not gonna scrape HTML to extract the JSON bits I'm interested in, and I understand that this settings API is undocumented and I should not rely on it; though I'd really like bringing the issue to the table, do we want clients to access this feature? I think that could bring consistency to the ecosystem.
Note that from a server side implementation perspective, that'd be just matter of enabling
GET
to the/api/web/settings
endpoint, exposing the settings as JSON, and documenting the feature officially.Thoughts?
The text was updated successfully, but these errors were encountered: