在ASP.NET Core中更改电子邮件工作流程 [英] Change email workflow in ASP.NET Core

问题描述

如果用户想要更改为新的电子邮件地址，我将使用:

If a user wants to change to a new email address, I use:

var token = await _userManager.GenerateChangeEmailTokenAsync(user, newEmail);

...并发送包含此更改令牌的确认邮件.用户单击电子邮件中的链接，回到站点，现在我需要更改电子邮件.

...and send a confirmation mail which includes this change token. The user clicks the link in the email, arrives back at the site, and now I need to change the email.

但是，我不知道新的电子邮件地址.

BUT, I don't know the new email address.

我已经经历了确认邮件循环的麻烦，所以我想使用它.再次要求发送电子邮件可能会造成大错特错，这可能会使用户无法进入自己的帐户，这也是用户遇到的另一个障碍，还有更多代码需要我维护.

I've gone through the hassle of an confirmation mail loop, so I want to use it. Asking for the email again risks mistypings that could lock out the user from his account, and is also another hurdle for the user, and more code to maintain for me.

显而易见的解决方案:

• 再次提出要求(并冒犯错误的风险，并使邮件循环毫无意义)
• 将新的电子邮件地址存储在User.NewEmailTemp中(是的，希望保持此状态为无状态)
• 将其包含在电子邮件的链接中(安全性很差！)

• ask for it again (and risk mistypings, and make the mail loop pointless)
• store the new email address in User.NewEmailTemp (yuck, want to keep this stateless)
• include it in the link in the email (bad security!)

可能有更好的方法.更改令牌包含一堆数据，其中包括包含新电子邮件地址的目的" .我可以以某种方式提取/解码该目的，还是将其作为哈希过程的一部分进行修饰?

There may be a better way. The change token includes a bunch of data, including a "purpose" which contains the new email address. Can I somehow extract/decode the purpose, or is it mangled as part of a hashing process?

推荐答案

答案仅仅是将其持久化.无状态并不是真正的选择.但是，这并不意味着您需要用它污染用户子域.例如，您可以创建一个单独的实体，例如EmailChangeRequest，并带有用于新电子邮件的道具，令牌以及可能的时间戳(主要用于修剪/过期).在这里，该令牌不是用于验证，而是用于查找，因此可以将其视为表上的键.

The answer is simply to persist it. Stateless isn't really an option. However, that doesn't mean you need to necessarily pollute the user subdomain with it. You can, for example, create a separate entity like EmailChangeRequest, with props for the new email, the token, and probably a timestamp (mostly for pruning/expiration). The token, here, wouldn't be for validation, but rather for lookup, so it could be considered a key on the table.

简短地说，当用户单击链接时，您将通过令牌查找请求，从中获取新电子邮件，然后使用该新电子邮件和令牌呼叫ChangeEmailAsync.

Long and short, when the user clicks the link, you look up the request via the token, get the new email from that, and then call ChangeEmailAsync with that new email and the token.

如果您真的反对任何形式的持久性，那么以前我个人都喜欢使用JWT风格的方法.我之所以说"-esque"，是因为传递一个完整的经过加密和签名的JWT作为查询或路由参数，这将使极端长URL用于确认链接，甚至可能接近请求限制.相反，我要做的是砍掉JWT的标头，因为标头主要用于跨客户端通信.在这种情况下，我可以放心地假设使用一种加密方法和颁发者，而这是不必要的.

If you're really opposed to persistence of any sort, I've toyed around personally with a JWT-esque approach previously. I say "-esque" because passing around a full encrypted and signed JWT as a query or route param is going to make for extremely long URLs for your confirmation links, perhaps even approach request limits. What I did instead, was chop off the header of the JWT, since the header is mostly meant for cross-client communication. In this scenario, I can safely assume an encryption method and issuer and such is unnecessary.

我进行的另一项更改是使用TOTP样式的令牌，而不是默认使用的加密哈希.这有助于进一步减小JWT令牌的大小，并且由于我正在加密JWT本身，因此内部的令牌本身是加密的并不那么重要.诸如电子邮件确认之类的令牌提供者可以是ConfigureServices中的="nofollow noreferrer">易于定制，并且有

Another change I made was to use TOTP-style tokens instead of the encrypted hashes used by default. This serves to further reduce the JWT token size, and since I'm encrypting the JWT itself, it's not that important if the token inside is encrypted itself. The token provider for things like email confirmation can be easily customized in ConfigureServices, and there's built-in TOTP token providers that can be used, so this is also relatively low-friction.

我仍然认为坚持下去并不一定是一件坏事，特别是如果您在用户子域之外使用单独的实体.但是，如果您不想走这种路线，那么伪JWT方法可能会更适合您的需求.

I still don't think it's necessarily a bad thing to persist it, especially if you use a separate entity outside of your user subdomain. However, the pseudo JWT approach might fit your needs better if you don't want to go that route.

这篇关于在ASP.NET Core中更改电子邮件工作流程的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！