search

kalevias / mesa

0 stars 1 forks source link

Users created in calendar access block the same email from being used for registration #14

Closed Outfenneced closed 8 years ago

Outfenneced commented 8 years ago

Self explanatory. To recreate: Run calendar access to a txTokenid associated with an email not already an "organizer", then attempt to create a user based on the same email on the main page. It will say that the email was already taken.

Could be fixed if I could insert a null into the txHash, txSalt, or dtLogin to identify them as non-registered. Another fix could be to have separate tables for organizers and attendees.

kalevias commented 8 years ago

Added here for redundancy: One possible solution for this issue is the following: When you create a new user in the services code, DON'T add a salt, (and also don't add dtLogin, as the user has never logged in to the system), but do include a password. Make the password a token with no expiration date. In the registration code, I can use this token password and lack of salt to check to see if the user should be registered, even though the account may already exist.

(also, for clarity, when I say password, I mean txHash)

Outfenneced commented 8 years ago

So I should generate a new thing in tblTokens and associate it with the email? I also found issues with excluding dtLogin and blSalt, as I believe they don't allow null values, or at least they don't have a default value that I can force insert. NULL will not work I'm pretty sure, because of this.

Outfenneced commented 8 years ago

Yeah, dtLogin and blSalt are NOT NULL in my database, at least.

kalevias commented 8 years ago

Alrighty, I'll modify the database so that these can be NULL, and I'll pull the updated copy to master.

And yes, just generate a new token (I'd use SHA256 on the current time (UNIX timestamp or whatever)) and store it in tbltokens along with the email of the user account you're creating.