.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 帐户的情况下引入人为延迟，但我更愿意找到一种方法来发送电子邮件而不阻塞 UI.

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);
}

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

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屋！