Some questions regarding implementing forgot password functionality in asp.net mvc
I want to implement a forgot-password feature in asp.net mvc that allows users to reset their password, and have some questions in this regard:
Lets say that before allowing users to reset their password, I want to verify some extra inform开发者_如何学编程ation such as their first and last name. This info is not stored by default in the table created by aspnet_regsql. What is the recommended approach to address such issues? Should I store this kind of info in a separate table, and use table joins to verify OR should i modify the schema of the table generated by aspnet_regsql (how?) so that I don't have to use joins? Do I need to write a custom provider OR would that not be necessary?
I have read at places e.g. in this post that instead of emailing a temporary password, an alternative is to email a URL that when clicked allows users to change their password. How is this done? How to ensure that the URL expires after 1 hour?
I could write at length several answers to the questions you pose. There are too many to get into implementation detail, but I'll try to hit the points that I've kept in mind when designing sites. Basically, you can (and should) work with the Membership provider instead of working around it. It's a bit of work but possible to do all of the following using the providers and ASP.NET MVC.
- Avoid accessing membership tables or executing membership stored procedures directly.
- Their structure and usage could differ in older or newer versions.
- The providers are already established to perform most tasks.
- LINQ other framework methods and help to do the rest.
- For 'extra' information like Names, use ASP.NET Profiles
- User email addresses should be unique.
- Users should create their own accounts.
- Administrators shouldn't create new accounts directly.
- Passwords and security answers should only ever be known to the user.
- A generated key (in the form of a URL) should be sent to verify ownership of the given email address before account activation.
- Implement a Security Question and Answer, which the Membership provider already supports.
- Provide good questions from which to choose.
- Don't force or trust users to think up a good question ad hoc.
- Question/answer can only be changed by knowing the current password.
- Forgotten passwords
- Can be reset by correctly answering the security question.
- Can be reset by administrative action if security answer is also forgotten or account gets locked.
- Resetting a password should mean:
- A generated temporary password is sent to the email address on the account. Temporary means:
- A flag (a Profile value) is set to indicate that the user must set a new password after next login.
- The password expires after a set amount of time.
- An administrator can reset a password, but should never know the password.
- Must be done using a second provider definition (see ASP.Net User forgot answer to password question)
- Should simultaneously unlock the account if necessary.
- A generated temporary password is sent to the email address on the account. Temporary means:
- Lock account after too many failed password or security answer attempts.
- Failed attempts are already counted and configured within the provider.
- Optionally unlock account automatically after enough time has passed.
I'll expand this if I think of any more.
I don't know if this is the recommended approach but you could create a separate table like you mentioned and then implement your own membership provider. That way on a password reset you can implement the additional functionality required.
For the second part: I would generate a token, read about a variety of ways to generate it here. You can store the token with a date/time, email a link to the user with the token as part of the URL, then you'd be able to check it against the amount of elapsed time, once the users clicks on it.
精彩评论