Logging in discourse using API - using discourse as API server only

Dev
1

I want to login discourse using API.

But there is no such API in docs.discourse.org.

I checked many questions regarding Q1, but I am surprised none of them correctly answer (other than ‘check the network logs and figure it out’). Can we not use discourse purely as api server? If we are having api docs, then I thought login would surely have been implemented.

If there any specific reason login has been left out?

(More explanation)
The docs.discourse.org suggests to pass the api_key to make the authenticated calls. But I do not want to use the master api key. Also I do not want to use discourse as SSO provider, and send the user to login page of discourse. I want to make login to discourse directly.

1 Like
2

You would have to adhere to our user API to log people in, that is what our mobile app does.

The protocol is quite involved and not super documented, recommend you read through the source of discourse mobile. https://github.com/discourse/DiscourseMobile

In particular:

https://github.com/discourse/DiscourseMobile/blob/master/js/site_manager.js#L453-L487

Either that or if you don’t need to allow the user to do this, just specify api_username when you make your API calls with the master id.

Yes Discourse can be used an API server.

10 Likes
3

The first one fetches the api key for user. Second method that you suggested is good for making automated requests on behalf of user.

But I want to build my own UI with discourse api.
So I want to call login api just like ember client does

I debugged the login flow of ember.

First it calls /csrf?_:18282829 to get a csrf token

Then it calls /session with username and password and csrf token and other headers.

Funny thing is if I intercept the session api call and make it myself(by sending all cookies and headers) I get Bad csrf error.
But the ember client can make the call successfully and get the user details.

So what is your csrf token strategy? Do you match session cookie and header, or is there something like secret in cookie and salt in header?

I tried to find in ruby code, but couldn’t do so. If you can point me to the file, then I will try to figure it out.

1 Like
4

Hello,

I’m heading down a similar path and stumbled across this topic. I’m curious how this would work in conjunction with SSO (we are trying to embed messaging into our existing SPA). Is an approach (post authentication in our app):

  • sso login the user (to ensure they are in discourse, though would using sso_sync, ahead of time or on-the-fly make sense instead?)
  • call APIs where we “just specify api_username when you make your API calls with the master id”

Apologies in advance if there are other, more up-to-date topics on this

5

In case there are other interested parties here: I did end up using the sync_sso api within my application to create/update the user in Discourse and retrieve their username for use in subsequent api calls to Discourse (using instance’s master api_key). Was a pretty straight-forward approach given Sync SSO user data with the sync_sso route

3 Likes