Spring/BlazeDS 消息拦截器用例
Spring BlazeDS 集成（在我们的示例中为 1.0.5M1）允许我们定义 MessageInterceptor 实例并将它们注册到消息代理中。我的问题很简单：有谁知道这个机制应该或不应该用于什么目的？
从API文档中我可以看到框架本身使用拦截器来集成Spring Security。我们正在考虑使用这些拦截器作为执行我们自己的特殊安全性的一种方式（我们在应用程序上下文中使用我们自己的服务跟踪用户），每次通过网络发送消息时都会评估条件。
我们意识到我们可能应该在某个时候集成 Spring Security 来更正式地处理这些事情，但目前消息拦截器似乎是一个好主意。
The Spring BlazeDS integration (in our cases 1.0.5M1) allows us to define MessageInterceptor instances and register them in the message broker. My question is simple: does anyone have any idea what this mechanism should or shouldn't be used for?
From the API documentation I can see that the framework itself uses interceptors for Spring Security integration. We were thinking of using these interceptors as a way of enforcing our own special kind of security (we track our users using our own services in the application context), where a condition is evaluated every time a message is sent across the wire.
We realise we should probably integrate Spring Security at some point to handle these things more formally, but for now the message interceptor seems like a good idea.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我不知道它是否“好”用例，但在我们的用例中，我们有一个呼叫中心，让每个人都能看到“最新”版本的数据非常重要。有数百人查看数据，可能有十几人可以更改数据。我们对其进行了设置，以便任何数据修改都会向所有客户端发送消息，如果客户端当前拥有该数据，那么它将被更新，并且如果用户正在查看的实际选项卡上的数据已更改，则会弹出一个对话框，否则数据只是在幕后发生变化而无人知晓。
I don't know if its "good" use case or not, but in our use case we have a call center where its very important that everyone see the "latest" version of data. There are several hundred people looking at the data, and maybe a dozen or so that can change data. We have it set up so that any data modifications send a message to all the clients, if the client has that data currently then it will be updated, and pop up a dialog if the data on the actual tab the user is looking at has changed, otherwise the data just changes behind the scenes with none the wiser.
自从我们实现这一点以来，以这种方式使用拦截器似乎没有引起任何问题，所以我认为这不会成为问题。
Seems that using the interceptors in this way hasn't caused any issues since we implemented this, so I don't think this is going to be an issue.