.NET Core替代ThreadPool.QueueUserWorkItem [英] .NET Core alternative to ThreadPool.QueueUserWorkItem

问题描述

我正在努力实现ForgotPassword功能，即在AccountController中使用ASP.NET Identity像在标准VS 2015项目模板中一样。

I'm working on implementing the ForgotPassword functionality ie in the AccountController using ASP.NET Identity as in the standard VS 2015 project template.

我遇到的问题尝试解决的问题是，发送密码重置电子邮件后，页面响应会明显延迟。如果密码恢复尝试未找到现有帐户，则不会发送电子邮件，因此响应速度更快。因此，我认为这种明显的延迟可以用于帐户枚举，也就是说，黑客可以根据忘记密码页面的响应时间来确定帐户存在。

The problem I'm trying to solve is that when the password reset email is sent, there is a noticeable delay in the page response. If the password recovery attempt does not find an existing account then no email is sent so there is a faster response. So I think this noticeable delay can be used for account enumeration, that is, a hacker could determine that an account exists based on the response time of the forgot password page.

因此，我想消除页面响应时间的这种差异，以便无法检测是否找到了一个帐户。

So I want to eliminate this difference in page response time so that there is no way to detect if an account was found.

过去，我将可能很慢的任务排队例如使用以下代码将电子邮件发送到后台线程：

In the past I've queued potentially slow tasks like sending an email onto a background thread using code like this:

ThreadPool.QueueUserWorkItem(new WaitCallback(AccountNotification.SendPasswordResetLink), 
notificationInfo);

但是.NET Core中不存在ThreadPool.QueueUserWorkItem，因此我需要一些替代方法

But ThreadPool.QueueUserWorkItem does not exist in .NET Core, so I'm in need of some alternative.

我想一个想法是在Thread.Sleep找不到帐户的情况下引入人为延迟，但我宁愿找到一种发送延迟的方法。

I suppose one idea is to introduce an artificial delay in the case where no account is found with Thread.Sleep, but I'd rather find a way to send the email without blocking the UI.

更新：为澄清这个问题，我发布了实际的代码：

UPDATE: To clarify the problem I'm posting the actual code:

[HttpPost]
[AllowAnonymous]
[ValidateAntiForgeryToken]
public async Task<IActionResult> ForgotPassword(ForgotPasswordViewModel model)
{   
    if (ModelState.IsValid)
    {
    var user = await userManager.FindByNameAsync(model.Email);
    if (user == null || !(await userManager.IsEmailConfirmedAsync(user)))
    {
        // Don't reveal that the user does not exist or is not confirmed
        return View("ForgotPasswordConfirmation");
    }

    var code = await userManager.GeneratePasswordResetTokenAsync(user);
    var resetUrl = Url.Action("ResetPassword", "Account", 
        new { userId = user.Id, code = code }, 
        protocol: HttpContext.Request.Scheme);

    //there is a noticeable delay in the UI here because we are awaiting
    await emailSender.SendPasswordResetEmailAsync(
    userManager.Site,
    model.Email,
    "Reset Password",
    resetUrl);


        return View("ForgotPasswordConfirmation");
    }

    // If we got this far, something failed, redisplay form
    return View(model);
}

是否有使用其他内置框架功能来处理此问题的好方法？ / p>

Is there a good way to handle this using other built in framework functionality?

推荐答案

只是不要等待任务。然后，这几乎等同于在线程池上开始运行所有代码，假设它在不调用 ConfigureAwait（false）的情况下内部没有任何等待。 （如果要检查的是您的代码，则需要进行检查。）

Just don't await the task. That's then mostly-equivalent to running all of that code on the thread-pool to start with, assuming it doesn't internally await anything without calling ConfigureAwait(false). (You'll want to check that, if it's your code.)

您可能要将任务添加到一组任务中假设ASP.NET中存在请求的关闭的适当概念，则应该在服务器关闭之前等待。这很值得研究，并且可以防止由于不幸的时机，在发送响应之后但在发送通知之前立即关闭服务器，从而使通知不会丢失。如果在发送通知时遇到问题，例如，不会提供帮助。您的邮件服务器已关闭。到那时，已经告知用户该电子邮件已经发送，而您不能真正保证...只是要考虑的事情。

You might want to add the task to some set of tasks which should be awaited before the server shuts down, assuming there's some appropriate notion of "requested shutdown" in ASP.NET. That's worth looking into, and would stop the notification from being lost due to unfortunate timing of the server being shut down immediately after sending the response but before sending the notification. It wouldn't help in the case where there are problems in sending the notification though, e.g. your mail server is down. At that point, the user has been told that the email is on its way, before you can really guarantee that... just something to think about.

这篇关于.NET Core替代ThreadPool.QueueUserWorkItem的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！