Remove UserId from ConfirmEmail action and impleme

2019-08-27 12:31发布

问题:

I would like to remove the UserId query-string from the ConfirmEmail action in the AccountController, as I do not want UserId's to be sent in email messages.

Once I do this, I will still need to obtain the UserId in order to call the method UserManager.ConfirmEmailAsync. In order to do this, I plan to require authentication for the ConfirmEmail action. This way I can call User.Identity.GetUserId() to obtain the UserId parameter needed to confirm the email address.

Upon logging in, if the user's email address is not confirmed, they will be redirected to the ConfirmEmail page. Additionally, I would like to implement a check on every page load to see if the user's email is confirmed and if it isn't I would like them to be redirected to the ConfirmEmail page.

My questions are as follows:

  1. How would I go about implementing this check on every page?
  2. Would there be a large performance penalty on checking if a user's email is confirmed on every page? If so, would it be better to store the confirmed value in a session variable and check that instead?
  3. If I do end up using a session variable can it easily be removed or changed by a user?
  4. Am I on the completely wrong track? Is there a better way of doing this?

Thanks for all your help!

回答1:

How would I go about implementing this check on every page?

You can use action filters for fulfilling this purpose. They work like charm with Method enter and Method exit strategy by simple applying attribute on the Action methods like AOP(Aspect oriented programming).

Would there be a large performance penalty on checking if a user's email is confirmed on every page? If so, would it be better to store the confirmed value in a session variable and check that instead?

It depends on how you implement it and how much is the cost of checking operation. Keeping information in session is alwasy an easy idea but it's not a good practice comes in picture later when you go for scaling the application across servers. Then you come back with session and types of session and what information should I store in session. So it again depends on various scenarios.

You can keep this infomration as simple flag in a cookie. Then you can create an action filter that would check for the cookie if it request has that information as e.g. "Not yet confirmed". If not just ignore it. you can invalidate the cookie once the user has confirmed the email address.