GWT 身份验证
我正在开发一个 GWT+Spring 应用程序,但在将 GWT 与 Spring Security 系统集成方面遇到了困难。
服务受到 spring security 的保护,并且对未经身份验证的用户(匿名)响应 401,对未经授权的访问响应 403。我的问题是,我无法让失败的 AsyncRequests 按照我想要的方式处理这些错误,而无需一次又一次地键入 onFailure 样板存根来进行该处理。
我已经成功地为 Spring Security 开发了自己的过滤器,它使用“authorizeform”标头进行响应,该标头带有 401 异常登录表单的 URL。
所以问题是: 有没有办法在没有样板 onFailure 代码的情况下全局处理 401/403 异常并从指定标头重定向到 URL?
即将推出的 RequestFactory 有类似“AuthenticationFailedHandler”的内容,但 2.1 几乎完全没有文档记录,并且“正在快速开发”,因此看起来它不是一个选项。
提前致谢!
I'm developing a GWT+Spring application and I'm having hard times integrating GWT with Spring Security system.
Services are protected by spring security and response with 401 for un-authenticated users (anonymous) and 403 for unauthorized access. My problem here is that I can not make failed AsyncRequests handle those errors the way I want without typing again and again onFailure boilerplate stubs for that handling.
I've managed to develop my own filter for Spring Security that respondes with "authorizeform" header that carries URL of login form for 401 exception.
So the question is:
Is there any way to handle 401/403 exceptions globaly without boilerplate onFailure code and redirect to URL from specified header?
Upcoming RequestFactory has something like "AuthenticationFailedHandler" but 2.1 is almost completely undocumented yet and "under rapid developement" so it looks like it's not an option.
Thanks in advance!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
在应用程序级别处理安全故障的一种非常简单的方法是为应用程序定义一个抽象回调,它将在一个一致的位置处理 onFailure 样板。对于整个代码中的每个服务请求,您将能够使用回调并实现任何特定的处理。
现在,您可以通过以下方式调用服务:
当然,如果您希望仅在应用程序级别进行错误处理,则可能需要将 onError 设置为具有空主体的非抽象方法。
A very simple way to handle the security failures at the application level is to define an abstract callback for your application which will take care of the onFailure boilerplate in one consistent place. For each service request throughout your code, you will be able to use the callback and implement any specific handling.
You can now call a service in the following manner:
Of course, if you would like the error handling to be only at the application level, you may want to set onError to be a non abstract method with an empty body.