小编ptf*_*ptf的帖子

我在这里阅读了一些有关电子邮件客户端预取电子邮件中的 URL 的问题。对此的答案似乎是添加一个新的确认页面，用户必须在其中单击按钮来确认所需的操作。

但是，这个答案指出了以下内容：

截至 2017 年 2 月，Outlook ( https://outlook.live.com/ ) 会扫描到达收件箱的电子邮件，并将所有找到的 URL 发送到 Bing，以便由 Bing 爬网程序编制索引。

这实际上使得所有一次性使用的链接（例如登录/密码重置/等）变得毫无用处。

（我的服务的用户抱怨一次性登录链接对其中一些人不起作用，而且 BingPreview/1.0b 似乎在用户打开收件箱之前就点击了该 URL）

Drupal 似乎遇到了同样的问题： https ://www.drupal.org/node/2828034

我主要关心的是这个声明：

截至 2017 年 2 月，Outlook ( https://outlook.live.com/ ) 会扫描到达收件箱的电子邮件，并将所有找到的 URL 发送到 Bing，以便由 Bing 爬网程序编制索引。

如果是这种情况，则电子邮件中用于确认操作（例如确认登录、订阅或取消订阅）的任何 URL 最终都可以在搜索引擎中搜索到（如果这就是上面引用中的含义）indexed。在本例中，它是 Bing。即使是用户确认所需操作的专用确认页面也无法真正缓解这种情况。

场景#1

如果我通过电子邮件向用户发送一个登录链接，其中 URL 中包含一次性令牌，则该 URL 最终将出现在 Bing 中。该令牌的生命周期很短，比如说 5 分钟，因此我怀疑是否有人会在用户点击该令牌或令牌过期之前在 Bing 上进行搜索并找到该 URL。

场景#2

用户会收到一封电子邮件，其中包含确认订阅的链接。此链接的有效期可能为 24 小时。这可能（？）足够长，以至于其他人在搜索引擎上偶然发现该链接并意外（或故意）代表用户确认订阅。

场景 #2 并不罕见，据我所知，使用双重选择加入甚至是最佳实践。

场景#3

取消订阅时事通讯底部的 URL。也许永远有效？您不希望在搜索引擎中公开搜索此内容。

假设所有一次性确认链接都位于用户确认所需操作的确认页面上。

电子邮件中的 URL 被搜索引擎（至少是 Bing）索引真的是问题所在吗？它们最终真的会被公开搜索吗？indexed如果不是，那么上面引用的内容是什么意思？ …

在我的 .csproj 文件中，我添加了以下配置：

<ItemGroup>
    <None Include="$(USERPROFILE)\.nuget\packages\microsoft.data.sqlclient.sni\1.0.19235.1\buildTransitive\net46\x64\SNI.dll">
        <!-- This is a workaround to include SNI.dll in the NuGet package resulting from the pipeline in Azure DevOps. -->
        <Link>x64\SNI.dll</Link>
        <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
     </None>
</ItemGroup>

但是，很难找到有关PreserveNewest实际工作方式的文档。我查看了各种 Stackoverflow 帖子，并从文档中找到了此页面，该页面在None元素部分下说明：

CopyToOutputDirectory 可选字符串。确定是否将文件复制到输出目录。值是：

1. 绝不
2. 总是
3. 保存最新

它并没有真正描述它是如何工作的。有人知道吗？它根据什么标准来决定什么是最新的？文件更改日期？其他版本元数据？“保留”是什么意思？

配置的目的是将SNI.dll文件复制到bin/x64目录，它成功地完成了。

根据这篇文章，您可以将请求 ID 附加到 Serilog 中的环境上下文（the LogContext），如下所示：

using (LogContext.PushProperty("RequestId", Request.Id))
{
    // Process request; all logged events will carry `RequestId`
    Log.Information("Adding {Item} to cart {CartId}", item, cart.Id);
}

这很好，而且似乎正在发挥作用。我有两种需要这个的场景：

• 将相关 ID 添加到 API 的每个请求的日志中。
• 为队列的每个消息读取添加相关 ID。

让我感到困惑的是，如果多个请求同时访问 API，或者我们同时处理多个消息，会发生什么情况。由于LogContext是静态类，我是否会意外地使用来自最初设置该属性的线程之外的另一个线程的值覆盖该属性RequestId？LogContext

假设线程 1 将RequestId设为1。在完成之前，线程 2 将 设为 ，RequestId因为2我们收到了另一个请求。现在，线程 1 会用作记录时2的值吗？RequestId我猜它不会，但有人可以解释为什么吗？根据 this this，将与现有属性同名的属性推入堆栈会覆盖它：

将属性推送到上下文将覆盖任何现有的同名属性，直到从 PushProperty() 返回的对象被释放为止，如示例中的属性 A 所示。

Serilog 是否对从该LogContext.PushProperty(...)方法返回的每个句柄有一个堆栈，或者其他什么？有什么办法可以覆盖RequestId，也许不需要 …