Biarity is experiencing issues with the /users/by-external/:external-id route in Discourse, which is essential for their Single Sign-On (SSO) setup. Despite trying various approaches, including appending .json, they receive an “Oops! That page doesn’t exist or is private.” error.
After investigation, simon clarifies that the external_id only exists in Discourse when sent with SSO parameters from the SSO provider site, which is not the case in this instance.
Biarity then reveals that they are using Discourse as the SSO provider and are trying to retrieve a user by their external_id. However, mpalmer points out that in this scenario, the user_id from Discourse should be used instead of external_id.
Ultimately, Biarity discovers that calling GET /admin/users/:user-id with the user-id provided by Discourse during SSO resolves the issue. They also inquire about the possibility of integrating with their client without supplying an API key, which would simplify their setup.
It’s essential when using Disocurse as an SSO provider since you need to know the usernames of a user, given their external_id. (And since usernames can change, I don’t want to manage storing them in my own database).
Any idea how to make it work? I tried appending .json with no luck.
Just shows an “Oops! That page doesn’t exist or is private.”.
Even on this site, my user id is 26582 (got it by GET meta.discourse.org/users/biarity.json under user:id).
Performing GET meta.discourse.org/users/by-external/26582 shows Oops! That page doesn’t exist or is private.
The external_id for a user doesn’t exist on Discourse until you send it with the SSO parameters from the site that is acting as the SSO provider. This site doesn’t use SSO, so it won’t work here.
Once a user has an external_id you can get the user by making a GET request to example.com/users/by-external/:external_id.json.
I’m doing the same request on my self-hosted discourse site (which is set up as an SSO provider), and still getting the same Oops! That page doesn’t exist or is private error. I’m using the external_id that’s been provided by discourse during SSO.
In my site, doing ( my external_id is 1): GET http://[MY DISCOURSE SITE]/users/by-external/1.json?api_key=[MY API KEY]&api_username=[MY API USER] still yields a 404.
Is your external_id1, or is your user_id 1? Can you show a dump of your single_sign_on_records table? Also, external_id is all about using another site as the SSO provider; if you’re using Discourse as the SSO provider, as you stated, you don’t need external_id because you’d use the user_id from Discourse to lookup the user.
Seems I was confused by the term external_id since it was included in the data sent by discourse during SSO. Apparently it’s supposed to be external to me, not to discourse (which makes sense now).
Calling GET /admin/users/:user-id (where user-id is the external-id given by discourse earlier) works well.
On a side note, is there a way of doing this without having to supply the API key? That would make integration with my client easier.