Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Too many assumptions that email implies a unique user - it seldom does in mature systems #520

Open
tblanchard opened this issue Mar 16, 2015 · 0 comments

Comments

@tblanchard
Copy link

I've really tried to like confide and make use of it. I'm finding it a muddled mess.

Problem 1) We have users with logins - and multiple emails addresses. Login is never email address.

When performing a 'forgot password', the reminder token, and the email address are saved. However this is wrong - you should save the user->id so you get back the exact user from the database.

Problem 2) When the password reset token is retrieved, the password reset token record is fetched, the email is pulled from it, and then the user is looked up by email. Why? You HAD the user's id when you saved the record.

Please read this article http://www.tdan.com/view-articles/5014

We are making use of this pattern. We have a party which has multiple names, multiple emails, and multiple logins. There is no hard unique 1-1 mapping between email and login. Yet this assumption is baked into confide at a very deep level and there is no good reason for it. Please deal with the login record with username (which might be email - or not) and use primary keys to save and fetch records that have already been looked up once.

I like the idea of this framework - but in practice I'm having a hard time with it due to this unfortunate assumption.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant