Some endpoints do not require any authentication, pretty much anything else will require you to be authenticated. To become authenticated you will need to create an API Key from the admin panel.
That’s too bad, because there are a lot of legitimate uses of the API
that regular users could make use of, not just admins.
E.g., a monthly cronjob a user might set up to download his
preferences.json instead of clicking Download in Preferences
(Backup/export/import Preferences).
I am saying that a change in the source code is needed, so soon users all over the world will be able to access the API of the local Discourse they are using, to get their personal data, etc.
However, without support from admins and an approved endpoint in the user api keys site settings “regular users” still can’t just generate their own api keys.
That response is incorrect. Any user can generate a user API key if the generation of user API keys is enabled for the user’s trust level. If you don’t set a redirect in the request payload it will display a base64 encoded response in the browser that contains the key.
See this topic for a script that shows how it is done.
I’m thinking for the default case where person A has installed Discourse,
and person B is just a simple user on person A’s Discourse,
and A has not changed any admin settings, could B still do much with the API?
The User API key generation is enabled for all users by default, and anything you can do through the web interface you can do through the API because the web interface is just a frontend to the API.
I personally use it in an extension in Chrome that keeps a running total of all my unread notifications across all the instances I have accounts on with a few exceptions.
If a user has an account on a Discourse instance already they should be able to use their same cookie authentication from the browser in any non-browser api requests.
