Reset password with custom ruby file

Custom function for password update in discourse

Can we use this code to update the password?

e.g:-
User.find_by(username: ‘gollum’).update!(password: ‘shiiiire!-BAGGINS!’)

Or

Can we create a custom plugin and use a custom endpoint like API
and create a token with user credentials then reset the password with API.

https://docs.discourse.org/#tag/Users/operation/changePassword

Please share best way to do this task

Hi Hitesh,

What would be your use case? Why not use the built-in feature?

1 Like

thanks for reply

I am using a custom script to migrate Drupal users to discourse but the password is saved as a hash string and the user can not log in with a reliable password like (admin@123)

But It login with their password hash like
e.g.:- 3sdfd32423@#423fdsfr

So can you please little explain regarding built-in feature

Have you had a look at this? It might help:

It supports Drupal 7 passwords:

1 Like

hi @Canapin

Also, I used this plugin but it is not working

No - it’s working.

This is one of the oldest third party plugins around (over 9 years old now!) and it has been maintained and working all the time. It might not be working for you but the way to solve that is to find why it is not working for you instead of trying an alternative route.

Can you please rephrase this? I don’t understand what you are saying.

Is my Drupal website storing user passwords in an encrypted code and keeping them in a database I moved all the users to a platform called Discourse using a dsiscourse API. I create a payload with their user details and password codes from Drupal’s database and put them into Discourse.

I thought users would be able to use their same login details on Drupal, but it’s not working. Discourse doesn’t accept the user’s actual password, like “admin@123.” Instead, it uses a user password hash code like “3sdfd32423@#423fdsfr.”

Discourse takes the password codes from Drupal and puts them into its own encrypted algo in its own database.

Can you show us how you did it?
If you have been using the API, you should not set the Drupal hash as the password. You should set the hash as a custom user field called import_pass. I’m not sure if that is even possible using the API.

1 Like

I followed your steps while installing the Discourse Migrate plugin

→ First I installed the plugin into my discourse but did not enable then created a
the custom field into discourse with the name import_pass

→ In the payload add the password hash stored in this custom field

→ After the user uploads into the discourse enable the plugin and log in new window with user credentials but they didn’t

This is explicitly not part of the steps.

There is a difference between creating a user field with that name, and having a custom field with that name. So the hash is being stored in the wrong place.

The problem is that I think that the latter (a custom field) is not accessible using the API.
I think the best way forward is to have some custom once-off code that moves the content of the user field to the actual custom field.

(I considered changing the plugin so it looks at the user field as well but I think surfacing those hashes to the user interface is a security risk, so not going to do that).

This will work, run it from a rails console (tagging you so you see the edit @Hitesh_Sharma )

ufkey = "user_field_#{UserField.find_by(name: 'import_pass').id}"
User.all.each do |u|
  if u.custom_fields.key?(ufkey)
    u.custom_fields[:import_pass] = u.custom_fields[ufkey]
    u.custom_fields.delete(ufkey)
    u.save_custom_fields
  end
end
2 Likes