我有一个大量使用 nonce（即一次性安全令牌）的 SOA。
我的应用从客户端获取一个随机数，对其进行验证，然后将一个新的随机数作为每个回复的一部分发送回所述客户端。每个回复中还包括在 nonce 验证后立即执行的业务逻辑操作的结果。
nonce 验证和生成在操作上与业务逻辑耦合，因为两者都是响应每个客户端请求而发生的。但是我不希望两者在代码中耦合。根据 SOA 原则划分它们的正确方法是什么？将安全性和业务逻辑分解为两个独立的服务，一个调用另一个作为对每个客户端请求的响应的一部分，是否太过分了？
【问题讨论】：
是的，将它们分开是有意义的。但我认为他们根本不应该互相了解（直接打电话给对方）。
我将深入研究如何实现类似功能的具体示例和技术。
在 Web 框架 Struts2 中，所有传入的请求在到达用户定义的对象（称为操作）之前都会经过一系列操作（称为拦截器）。然后该操作将访问业务层。
提交网络表单时会出现重复提交的问题。因此，防止这种情况的一种方法是使用与表单提交一起发送的令牌。所以我们需要创建一个唯一的token，把它作为一个隐藏字段，然后当我们收到请求时，只有在token是好的时候才处理它。这可以防止用户多次意外购买某些东西。
在 Struts2 中有一个特殊的服务器端令牌标记，它为我们创建隐藏字段。因此，对于每种形式，都需要做一些事情。令牌拦截器如果处于活动状态，将强制该值始终存在并且在接收表单时很好，并将重定向其他地方不存在的响应。
实现一个 nonces 拦截器/过滤器来检查传入的 nonce 值是否正确，并为响应添加正确的 nonce 值到响应中的想法应该完全独立于业务逻辑。
这里的示例是使用 html 表单，但添加了一个拦截器（或任何你称之为“在请求/响应级别处理横切关注点”以用于您的适当技术），它将这样的值添加到 json 或 xml 消息应该是非常简单，可能会产生最优雅的结果。
以下是struts2拦截器参考的链接（它可能会更好地阐明这个想法）： http://struts.apache.org/2.2.1.1/docs/interceptors.html
以下两个链接都是管理令牌的拦截器： http://struts.apache.org/2.2.1.1/docs/token-interceptor.html
http://struts.apache.org/2.2.1.1/docs/token-session-interceptor.html
我希望每个链接的前几段会有用，但对于您的技术来说，类似的内容应该很好。
【讨论】：
我认为您在上面概述的内容符合 SOA 原则。您将两组不同的操作分开 - 一旦服务具有业务逻辑，另一个具有安全逻辑。
如果您拥有（或可能拥有）其他依赖随机数的服务，则尤其如此。
【讨论】：