I have an API key for my WordPress instance, but also would like to create a second API key for a Google Drive form. However, when I go to /admin/api
I see buttons to regenerate my existing key or revoke it, but no option to create an additional key. Is this a UI oversight or by design?
When we designed the API key stuff we didn’t really consider that people might want to have multiple API keys for the same account.
I think this is something we should correct, as there is totally a valid use case to give different API keys to different services. It’s not a simple change though unfortunately.
I see that it is old topic, but i couldn’t find new one, so i will just ask here.
I know that you guys introduced multiple API keys, and they can be added from discourse UI for specific user.
The question is, is it possible to generate api_key for specific user on its creation, or any time after, but not from the UI.
I want to give api_key to user with the API, with main api_key.
Thanks!
That is definitely doable in a plugin.
You can generate an API key for a user with this API call:
Request URL:http://localhost:3000/admin/users/4/generate_api_key
Request Method:POST
Request Body:
api_key,
api_username
The response json will look like:
{
"api_key": {
"id": 2,
"key": "630f51d28da39e969eaf26060687449df5ba443b517167a7ae393549a168bdb3",
"user": {
"id": 4,
"username": "discourse2",
"avatar_template": "/letter_avatar_proxy/v2/letter/d/4af34b/{size}.png"
}
}
}
Perfect guys!
That’s right what i need.
Thanks a lot.
I have just one more question.
To explain a situation first :
We have on one side discourse forum, and on the other FE application, where we show some of the topics,
and also allow users to comment on topics.
Until now all communication was through our BE, so if i want to create a topic, or comment on it, we had a method on our BE, which will do that job with main API_KEY and also with user who has admin privileges.
The idea now is to avoid all of those communication through BE, and directly create posts and make comments from client side. That’s why i asked is it possible to create api_key for specific user.
Now the question, finally, is this ok from security perspective?
So when i create api_key for specific user, that api_key will have rights like that user has on forum,
because that api_key will be exposed on client side?
Main goal is to get rid of communication through BE, at least some of it (creation of users and other sensitive stuff will still remain on BE side).
But creating posts and replying to them, we still want to be doable by users. So api_key will be used from client side.
So do you suggest to do something like this?
Thanks a lot.
and keep up with good work!
Probably should still funnel all front-end requests to your back-end first, then use the appropriate api_key for the user and have the back-end make the api call to discourse.
If you do want to keep in all on the front-end, I would generate a new discourse_api key every time the user logs in to your app. You will also have to setup CORS on discourse to accept the requests from your front-end.
You could also implement SSO (single-sign-on) so your users could just use discourse directly without having to login again.
we are using SSO, and basically both (discourse and FE) are on the same server, so no need for CORS, but still i was not able to create post without api_key, so i thought it is safer to use api_key of specific user.
Are you saying that there is a method for creating post without using api_key?
If i am sso logged in to discourse, of course
No. I was just suggesting that they leave your app and use the actual discourse forum to make the post if they are already logged into it.
yes, but it is not that easy
anyway, if the api_key, has only rights like that user on the forum?
than this option is acceptable.
because with that api_key user can’t do much.
but if that api_key has the same rights like admin, than we should avoid it.
this was more like a question?
what rights specific user api_key has?
admin or that specific user rights?
Thanks
the exact same rights that that user would have if they were logged into discourse.
perfect!
right what i need.
Thanks again!
If I remember correctly, there are a few exceptions, like being exempt from some rate limiting – maybe a team member (@sam?) can clarify this?
I think there are some specific api number of requests rate limits, but I would think these user limits would be hit first:
I’m pretty sure that the user API is distinct from the API the admin-generated user API keys work for
I would like much more fine-grained management of API keys also. I’ve come up with a hacky solution that will allow this to mostly work: