Generating User Api Keys with REST API

I am also looking for same solution, can anyone help in this?

Hello,

to generate an api key for a user:

curl -X "POST" "http://localhost:4000/admin/users/1/generate_api_key?api_key=10efbf2c9a84dfb3b6f60ffa117c029bda7fc9fb8f861ccd0dc8e8fbfa86968d&api_username=joffreyjaffeux"

Learn more about it:

2 Likes

@joffreyjaffeux That’s not the same “API” that @Umer_Mirza was asking about. I put “API” in quote because it may not exist?

The User API keys specification RFC talks about the use case of allowing users themselves the ability to request and API key so that a third party developed app may perform actions on their behalf. You would never want to give a third party your site API key because they would have full access.

I would ask this question in User API keys specification but that topic is closed. Does the API that @sam proposed in that post actually exist or not?

Yes user api keys exists and are consumed by the mobile app, look at the source code of the mobile app for exact specifications for now.

I would love to have this better documented so if you want to take that project on :heart:

4 Likes

Awesome, thanks for the quick response.

Well, maybe I can get something started for documentation. I have to do something on this front anyway so I can post what I come up with here.

2 Likes

This is the endpoint sam is talking about I think:

2 Likes

Thanks @joffreyjaffeux. I was drafting a similar message but I only had the code from the mobile app. These other code snippets are very useful.

When I tried this API against my own server using Postman, I kept getting a 400 error with no details. My Ruby is a little rusty but I’ll dig into the code more but if you happen to know why a 400 might happen that would be helpful.

I just tried adding my site to the official Discourse app, and it worked so I must be doing something wrong with regard to using the API in Postman.

Aside: I thought the app only worked for officially hosted Discourse sites. :man_shrugging:

I’m getting error code 400 when I visit https://community.frontrowcrew.com/user-api-key/new

3 Likes

Can I get some assistance on this @sam?

Did you want to purchase a hosting contract with us?

No, but if you can point me in the right direction I’d be happy to document it for others.

By looking at the URL generated by the discourse android app, I’ve uncovered the fields required for
/user-api-key/new

  • scopes - these are the permissions of the api key, in the case of the official app, to read notifications and to read session info
  • client-id - hex string, dunno
  • nonce - another hex string, used as a cryptographic nonce
  • auth_redirect - url to redirect to after permission is given
  • application_name - the name to display to the user of the application using the api
  • public_key - a public RSA key

Still a few questions:

  • What are all the valid values for scopes?
  • Where does the client-id come from?
  • Are all api responses encrypted with the public key or what is it’s purpose?
2 Likes

So, looking at the source code, client-id is 32 random bytes and nonce is 16 random bytes.
Edit: It’s actually 32 & 16 nybbles, but the code generating it is called randomBytes(32)

Found the scopes!

I’ve written a program that generates URLs of this specification, enough to get me to this screen:
2018-04-02-162159_516x297_scrot
But when I press Authorize I get a 403.

After authorize you will be redirected, so the redirect URL needs to go somewhere where you can handle decrypting the payload it redirects with.

Also there is a site setting that lists where the redirect is allowed to go.

4 Likes

Ok, got my api key. Is this a different API than the admin one documented at http://docs.discourse.org ?

When I try to make a post with the api documented at http://docs.discourse.org using a user api key, it says

You are not permitted to view the requested resource. The API username or key is invalid.

So I think it’s a different API or needs different fields (client_id?) for authentication.

A user API key behaves differently from the API keys described at docs.discourse.org. Instead of supplying it as a GET parameter, you need to send it as a request header.

I just updated the ‘consuming the API’ section of this wiki a couple of days ago, which may be useful to you:

7 Likes