如何解决Ajax调用CAS保护资源的跨域问题？
当尝试对位于与 CAS 服务器不同的服务器上的受 CAS 保护、SSL 加密的资源进行 AJAX 调用时，出现重定向问题，有哪些潜在的解决方案？
CAS 服务器用于身份验证并按照设计运行。这个问题似乎是 ajax 特定的。
这里有一个类似的问题，但我们不能使用相同的域/server/port 用于 CAS 服务器和后端资源。
JASIG CAS 邮件列表提到使用 JSESSIONID。
另一种可能的方法是修改 CAS 过滤器，将过期票证默认行为更改为更稳健的行为。
您将使用什么设计模式来解决这个问题？
What are potential solutions to a redirection problem that occurs when trying to make AJAX calls to a CAS-protected, SSL-encrypted resource located on a server different from the CAS server?
The CAS server is used for authentication and behaves as designed. This issue appears to be ajax-specific.
There is a similar question here, but we cannot use the same domain/server/port for the CAS server and the backend resource.
The JASIG CAS mailing lists mentions using JSESSIONID.
Another possible approach is to modify the CAS Filter to change the expired-ticket default behavior to something more robust.
What design pattern would you use to overcome this issue?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我有两个建议：
I have 2 suggestions:
我从未听说过 CAS，但总的来说：Javascript 有一些称为“同源策略”的限制。可见资源也不会自动对 Javascript 可见。您是否尝试使用反向代理访问资源以使其在同一域中可用？您还可以考虑将您的域指向一个单独的 Web 服务器，并将两台服务器作为反向代理（对于 Tomacat，JKmount 更合适）。
I never heard about CAS, but in general: Javascript has some restriction called “same origin policy”. A visible ressource is not automatically visible to Javascript, too. Did you try to access the ressource using a reverse proxy to make it available within the same domain? You could also consider to point your domain onto a separate web server and include both servers as reverse proxies (for Tomacat, JKmounts are to prefer) here.