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.
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.
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.