Tomcat 6.0.29升级到6.0.33破坏CAS认证，redirectAfterValidation是罪魁祸首？

发布于 2024-12-13 19:36:06 字数 753 浏览 2 评论 0原文

我们有多个 Web 应用程序，以及针对同一 Jasig CAS 实例进行身份验证的外部设备。这在 tomcat 6.0.29 上运行得很好，但升级到 6.0.33 后一切都崩溃了。

我们发现这是我们的验证过滤器重定向的问题，因为在我们的 CAS 验证过滤器中添加以下 init-param 修复了我们的 web 应用程序之间的通信：

<init-param>
    <param-name>redirectAfterValidation</param-name>
    <param-value>false</param-value>
</init-param>

我们最终了解到这是必要的，因为 tomcat 6.0.33默认情况下，enables 将其设置为 true，而最初设置为 false。问题是，现在我们的外部移动设备无法完成完整的身份验证会话，因为它不会重定向。

移动设备身份验证成功，但身份验证后，我们的 CAS 发送 http 内部服务器错误 500 并停止运行，没有任何有用的调试日志记录。将 redirectAfterValidation init-param 值更改为 true 可以修复此问题。

我的问题是，如果这之前在默认值为 false 时有效，为什么现在不起作用？ 6.0.33 中还有我没有看到的其他更改吗？抱歉，如果这个问题有点模糊，当有人问我时，我会尽力补充。

原文

We have several webapps, as well as an external device authenticating against the same Jasig CAS instance. This worked fine and well with tomcat 6.0.29, but after upgrading to 6.0.33 everything broke.

We found that it was an issue with our Validation Filter redirection, because adding the following init-param in our CAS Validation Filter fixed communication between our webapps:

<init-param>
    <param-name>redirectAfterValidation</param-name>
    <param-value>false</param-value>
</init-param>

We eventually learned that this was necessary because tomcat 6.0.33 enables sets this to true by default, where it was originally set to false. The issue is, now our external mobile device cannot complete a full authentication session because it does not redirect.

The mobile device authenticates successfully, but after authentication our CAS sends an http internal server error 500 and kaputs with no useful debug logging. Changing the redirectAfterValidation init-param value to true fixes this though.

My question is, if this was working before with the default value to false, why doesn't this work now? Is there another change in 6.0.33 that I'm not seeing? Sorry if this question is a bit vague, I'll try to add as much as I can when asked.

分享到QQ

分享到微博