PUT /u/{username}.json does not change the email

Contribute Bug

AI-generated summary

The PUT /u/{username}.json endpoint does not change a user’s email address, despite the Discourse API Docs suggesting it should. Canapin pointed out that changing the email address actually uses the /u/{username}/preferences/email.json endpoint, which sends a confirmation link to the email address that must be manually approved by the user.

xbd pointed out that this can be problematic when using a custom-made auth server that handles email confirmation, as it can result in multiple confirmation emails and different datasets. JammyDodger suggested using the auth overrides email admin setting to address this issue, while pfaffman advised configuring the authentication server to tell Discourse that the email address has been validated.

As a result of this discussion, blake updated the API docs to remove the email property from the PUT /u/{username}.json endpoint, which should save time spent on debugging in the future.

1

According to the Discourse API Docs (Discourse API Docs), it should be possible to change the email via the referenced endpoint.

  1. Use this API-Endpoint: PUT /u/{username}.json
  2. Use this request body:
{
    "Name": "Test Name",
    "Email": "test@test.com"
}
  1. Received 200 OK. Name will change, Email not.

The response does not contain the “email” field.

1 Like
2

I recommend that you Reverse engineer the Discourse API and see what api call to use.

2 Likes
3

Hi xbd,

According to the documentation, changing the email uses this endpoint: /u/{username}/preferences/email.json: https://docs.discourse.org/#tag/Users/operation/updateEmail

However, it will send a confirmation link to the email address to be manually approved by the user. Until then, the email won’t be changed.

5 Likes
4

Thank you for your assistance. Maybe helpful to remove the email property from the PUT /u/{username.json} in the documentation. Could save time spent on debugging ;-).

The thing with the confirmation mail: I read about it on another topic. I don’t get the point. Just in case, Discourse is an application of many others in the project and the authentication of users is handled by a custom-made auth server (like my case). The auth server handles email confirmation. The applications should just do, what the auth server says. This is in my opinion the normal way. Otherwise it comes with multiple confirmation mails, different datasets…

2 Likes
5

Thank you for raising this. This is weird indeed. It may be a remnant of a past era. I’ll get some info and update the doc if needed. :+1:

2 Likes
6

Does the auth overrides email admin setting help with this?

4 Likes
7

Then you need to configure it to tell discourse that the email address has been validated and not update email on the API, but on your authentication server.

2 Likes
8

Thanks again for bringing this up and sorry about the time spent debugging. The API docs have been updated.

3 Likes