背景
我们有非常严格的审核要求，并且希望能够将系统代表用户执行的每个操作与特定的身份验证操作（登录）关联起来。除了这些严格的审核要求之外，我们还有一些复杂的授权要求，这些要求是基于简单声明的授权所无法解决的。
综合考虑这两种情况，我开始考虑使用“信封”类型设计的可行性，在这种设计中，来自用户请求的消息被封装在一个信封中，信封中包含必要的信息，比如它们的auth令牌和有关发送机器的信息。但这看起来很俗气，而且由于它是一个相当交叉的问题，我宁愿它不污染系统中的每个协议，所以我觉得信封这个主意值得考虑。这种方法还需要系统中每个参与者的合作，我的目标是使这一点对不需要任何此类信息的参与者透明，而且还可以在参与者需要时提供信息。在参与者需要信息的情况下，直接接受信封类型也可以。

想象的解决方案

概述

• 将每个Tell操作 Package 在一个用于传输所需上下文信息的信封中
• 可能通过自定义执行元引用提供程序和包含已配置内容的执行元引用来实现
• 在每个接收操作时展开信封（如果存在）
• 自定义邮箱
• 还将处理向审核服务发送消息
• 如何使上下文信息对参与者可用？
• 我们能以某种方式添加到actor的Context对象吗？
• 在这种情况下，参与者也可以接受信封类型/不使用自定义邮箱

讨论

为了使这一切透明化，我最初的想法是“拦截”发送/接收操作。我对www.example.com的了解akka.net足以实现自定义邮箱，我认为这将是这种方法的可行之路，但是我也可以考虑其他的想法。邮箱将执行解包，并在需要时向参与者提供上下文信息（99%的情况下不是这样，当需要显式的信封时，最好直接接受信封）。邮箱还将通过向审计服务发送包含所需信息的消息来满足审计要求，所需信息不仅包括来自请求的上下文信息，还包括本地计算机信息，以了解在哪里/谁进行了处理。
我对自己的第二个猜测是拦截发送操作（Tell）。由于IActorRef示例是通过配置的IActorRefProvider创建的，并且由于这个家伙处理Tell操作（通过它创建的IActorRef示例）、我认为编写一个自定义的IActorRefProvider和一个自定义的IActorRef是有意义的。（装饰器模式），而自定义的IActorRef将在其Tell方法中提供所需的行为。（仅用于用户入口点），它将从HttpContext中提取所需的上下文信息（一个自定义引用提供程序）和后端应用程序（另一个自定义ref提供程序），它将从当前消息的上下文中提取所需的上下文信息。但我想这是可能的。
有了这两个部分，上下文信息将有效地在参与者之间和服务之间传递。因此，即使一条消息有20个参与者，如果它最初是由用户通过REST API发起的，它仍然会有上下文信息，从而允许对我们的系统从特定登录开始执行的每个操作进行全面和完整的审计和跟踪。
我所希望的
我希望这篇文章的主要目的是验证这是一个合理的方法，如果不是，如果自定义邮箱/actor ref/actor ref提供程序和额外的cookie所做的事情与我在这里尝试完成的类似，那么我们也非常欢迎您提供任何代码示例。另一个受欢迎的小花絮是如何进行邮箱配置，这样我就不需要用自定义邮箱实现手动更新我所有的Props了。Akka.net配置绝对是我的一个弱点，特别是部署部分，所以这里的任何核心知识/文章/建议都非常感谢！
感谢您花时间阅读本文！任何和所有的帮助是***非常***感谢！

其他堆栈溢出问题：

在这些问题中提供的答案需要每个参与者的合作。理想情况下，这是完全透明的，不需要使用这些上下文信息的参与者可以被写得好像它不存在一样。

• Passing Contextual Information
• How to elegantly log contextual information along with every message

我看了其他几个[由于某种原因现在找不到]，但它们都需要合作或全局共享状态[这不是akka避免的吗？：p]