Registration Process or linking to other DB

(Gilbert) #1

I’ve got an install of Discourse that upon submitting a registration and ideally after confirming the account, I need to copy username and password into a MySQL database using SHA256, not PBKDF2. I was initially thinking of just changing the registration process to accommodate that, however the password would already be salted and encrypted by that point.

I’m not familiar with Ruby on Rails either, what’s the best place to start looking at in the source to achieve this?

Use discourse for SSO in a non-web app?
(Manthan Mallikarjun) #2

Why not use SSO? Either host your own SSO or use discourses endpoint.

(Kane York) #3

@michaeld has an import-password plugin.

(Gilbert) #4

Hosting a SSO is more labor intensive than we’re really wanting to get into.

(Manthan Mallikarjun) #5

If im not wrong, Discourse can also function as a SSO endpoint.

(Kane York) #6

That doesn’t particularly help @Root, though…

The “import password” plugin is the way to go here.

(Michael - #7

I don’t see how the plugin would help in this use case… apart from learning where to put the hook for this…

Override the User.confirm_password? function, this gives you access to the plaintext password so you can hash it. Call super to verify the password, then store the hased password in the external db.

(Sam Saffron) #8

A much simpler approach here is sending password resets to all users when you move with a bit of a story about the new forum.

Transplanting auth is strongly not recommended and will end in lots of pain.

(James) #9

I can help clarify our intentions, as I am collaborating with @Root.

The purpose of this is not to offload authentication or login. We have a 3rd party server application that uses a MySQL database for authentication. We consider it a necessary feature to have our users sign up on our discourse community then be able to log in to the client using the same credentials. This way we can also ensure that the users are not signing up for additional accounts (we limit to 1).

We’re looking to have this completed at the same time as the user’s registration in discourse. Here’s how we’d like to get this to work:

discourse hashes user’s plaintext password and stores it normally
— IN ADDITION TO THAT we have some things we would like to do on our end.
$var1 (variable that we define)
$randomSalt (specific length)
$randomString (specific length)
$password (user’s plaintext password)

hash the following ($var1+$password+$randomSalt) using SHA 256
store the above temporarily, then once user activates
insert username, password(hashed), $randomString and $randomSalt (the one generated while hashing the user’s password) into the third party MySQL databse.

It has to be done this way as our application is hard coded to authenticate that way.

Could this be written in a plugin? How feasible is it for someone with somewhat basic knowledge of ruby to be able to do this? We’d also be willing provide compensation if someone could help us with this. Obviously, not a core feature for Discourse, but something custom for us.

(Sam Saffron) #10

This could be done in a plugin but its rather tricky, (also quite a bit confusing imo) another option is to have discourse act as an sso provider and just have users login using discourse everywhere.

(James) #11

Unfortunately, this would be too labor intensive for us. We’d have to write an entire web application to be able to register with the Discourse SSO and also rewrite the binary application’s entire authorization code.

It wouldn’t be easier to hop in to Discourse’s registration module and get the plaintext password there? Otherwise, if we try to use SSO, we only have Discourse’s hashed password, which is of no use to us as our application cannot read it.Our application compares the hash method listed above with that randomly generated salt for authentication.

(Kane York) #12

Wait, wait, what? I thought you already had hashed passwords and wanted to let people sign in using either.

Now you’re trying to create new hashes with the weaker algorithm? (sha256 is rather fast, and fast = bad with passwords)

(Michael - #13

Guys, guys, read what the man is saying, he has an existing application he cannot modify and he wants accounts to be provisioned in it’s database:

Yes, it can be done in the way I said some posts ago. We don’t do development work if people are not hosting customers though, but there should be enough people here who can help you.

(Sam Saffron) #14

I read this carefully, sso is the best option here, having auth in 2 spots using 2 schemes is just weird and error prone.

Anyway @Sequence if you insist on doing this, you can monkey patch this in a plugin.

(James) #15

So, obviously this is a complex situation and our solution is in no way ideal.

If we had access to the source code to both the client and server for our application, then we’d probably just re-write them to make SSO or oAuth work. We’re stuck with having no access to the source code of the client, which uses straight login/password authentication. We have no way to modify the front end to add a button to login with Discourse or any other oAuth provider. The user has to enter their password.

I could probably write a PHP script that uses the Discourse SSO to register a user with the program, but that doesn’t alleviate the fact that I need to get a password from the user and store it in a format that our program can read. I feel that this would be less secure than hooking into Discourse’s registration.

@riking We don’t have a choice, that is how our other application handles registrations and auth on its own. I did some testing with Discourse’s hashing method and I couldn’t get our program to read the password.

@michaeld Thank you. Appreciate the advice and helping to clarify.

@sam Is that the function we’d have to override in our plugin? Do you have any suggestions on where we could store information on our MySQL database (i.e. username, port, pw, ect.).

(Kane York) #16

Actually, I think that you could POST username & password to Discourse and it will reply with the same response as does (if the login is successful) from wherever the client is submitting the UN/PW to.

Use discourse for SSO in a non-web app?