Web 策略代理的重定向循环问题?

发布于 2024-11-16 06:44:27 字数 830 浏览 4 评论 0原文

我遵循安装指南 对于 Apache Web 策略代理,但它总是会导致 Web 和应用程序服务器之间的无限重定向循环。 Firefox 说“该页面没有正确重定向”,而 Chrome 则认为“该网页存在重定向循环”。该设置是端口 80 上的 Apache 2,带有一个小型演示应用程序和 Web 策略代理,以及端口 8080 上的 Tomcat 7 服务器,带有 OpenAM 服务器(Sun 的前 OpenSSO):

) HTTP 标头 Firefox 插件显示策略代理和 OpenAM 服务器(即 Apache 和 Tomcat 服务器)相互重定向,尽管服务器正确设置了 SSO 令牌 Cookie。 SSO 令牌 Cookie 的名称具有默认值“iPlanetDirectoryPro”。知道如何解决这个问题吗?

I followed the installation guide for an Apache Web Policy Agent, but it always results in an endless redirect loop between web and application server. Firefox says "The page isn't redirecting properly" and Chrome thinks that "This webpage has a redirect loop". The setup is an Apache 2 on port 80 with a small demo app and a Web Policy Agent, and a Tomcat 7 server on port 8080 with an OpenAM server (the former OpenSSO from Sun):

The Live HTTP Header Firefox plugin shows that the policy agent and the OpenAM server (i.e. the Apache and Tomcat servers) redirect to each other, although the server sets the SSO Token Cookie correctly. The name of the SSO Token Cookie has the default value "iPlanetDirectoryPro". Any idea how to solve the problem?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

べ映画 2024-11-23 06:44:28

整整一周后,在 Stackoverflow 和 OpenAM 邮件列表。有两个主要问题:丢失日志文件和丢失 cookie 域。安装 OpenAM 服务器和 Web 策略代理很困难,有大量日志文件和许多不同的配置选项。如果您选择了错误的选项,它将不起作用。如果不知道发生了什么,就不可能让它工作,这只能通过合适的日志文件来确定。

Web 策略代理缺少日志:必须在“Java 属性”文件中设置日志级别。 Web 策略代理有两个“Java 属性”文件:OpenSSOAgentBootstrap.propertiesOpenSSOAgentConfiguration.properties。名为 com.sun.identity.agents.config.debug.level 的日志和调试级别可以而且必须在两个 (!) 文件中定义,并且应设置为高级别, 全部:4全部:5。格式很重要。即使您这样做,AgentConfiguration.properties 文件也仅在代理未在集中配置模式下工作时使用。配置文件必须设置为“本地”。

缺少 Cookie 域:不要忘记在开始设置 OpenAM 服务器时输入正确的 Cookie 域,如果缺少,请稍后添加。在 OpenAM 服务器上,转到 Configuration >系统> Platform 并将 Cookie 域值更改为您的域(例如 .example.com)(如果缺少)。否则浏览器将在重定向过程中丢失您的 cookie。不知何故,我在 OpenAM 服务器上的 cookie 域有一个空条目,我猜忘记了一个点(example.com 而不是 .example.com),所以它是无效(或类似的东西)。

这个故障排除网站有助于查找问题。

After a whole week I finally figured it out, with the help of Stackoverflow and the OpenAM Mailing list. There were two main problems: missing log files and missing cookie domains. Installing the OpenAM server and the Web Policy Agent is difficult, there are a lot of log files and many different configuration options. If you select the wrong options, it won't work. It is impossible to make it work without knowing what is going on, which can only be determined by a suitable log file.

Missing Log for Web Policy Agent : The log level must be set in the "Java properties" files. There are two "Java Properties" files for the Web Policy Agent, OpenSSOAgentBootstrap.properties and OpenSSOAgentConfiguration.properties. The log and debug level which is named com.sun.identity.agents.config.debug.level can and must be defined in both (!) files, and it should be set to the high level, all:4 or all:5. The format is important. Even if you do this, the AgentConfiguration.properties file is only used when the agent is not working in centralized config mode. The profile must be set to "local".

Missing Cookie Domain: Do not forget to enter the right Cookie Domain during the setup of the OpenAM server in the beginning, or add it afterwards if it is missing. On the OpenAM server, go to Configuration > System > Platform and change the Cookie Domain Value to your domain (for instace .example.com) if it is missing. Otherwise the browser will lose your cookie during the redirect process. Somehow I had an empty entry for the cookie domain at the OpenAM server, I guess a forgot a dot (example.com instead of .example.com) so that it was invalid (or something like that).

This troubleshooting site was helpful to locate the problem.

梦醒灬来后我 2024-11-23 06:44:28

@0x4a6f4672,你的帖子绝对有帮助。还有一些内容可以添加到您的答案中。以下更改是我必须在配置中执行的操作才能使其运行,至少让它在户外运行。

com.sun.identity.agents.config.user.mapping.mode=USER_ID(Dont use HTTP_HEADER)
com.sun.identity.agents.config.user.attribute.name=uid
com.sun.identity.agents.config.user.principal=true(Dont use false)
com.sun.identity.agents.config.user.token=SsoUserHeader(Keep it as per what is specified in you application- in my case alfresco)

现在,您不是在集中模式下运行代理,而是在本地模式下运行代理,为配置文件属性指定的设置只能通过属性文件设置,因此添加以下内容。

com.sun.identity.agents.config.profile.attribute.fetch.mode=HTTP_HEADER
com.sun.identity.agents.config.profile.attribute.mapping[uid]=SsoUserHeader(whatever you want the header to come in browser as)

正如 0x4a6f4672 所说,很难调试,除非您处于本地模式,因此请立即切换到本地模式并开始跟踪日志并相应地更改属性。

@0x4a6f4672, Your post was absolutely helpful . Some more to add to your answer. The following changes is what i had to do in the config to make it running, at-least getting it running it for alfresco.

com.sun.identity.agents.config.user.mapping.mode=USER_ID(Dont use HTTP_HEADER)
com.sun.identity.agents.config.user.attribute.name=uid
com.sun.identity.agents.config.user.principal=true(Dont use false)
com.sun.identity.agents.config.user.token=SsoUserHeader(Keep it as per what is specified in you application- in my case alfresco)

Now you are not running the Agent in centralised mode but in local mode the setting which is specified for profile attribute can be only set via property file so add the following.

com.sun.identity.agents.config.profile.attribute.fetch.mode=HTTP_HEADER
com.sun.identity.agents.config.profile.attribute.mapping[uid]=SsoUserHeader(whatever you want the header to come in browser as)

As told by 0x4a6f4672, it is difficult to debug and unless you are in local mode , so switch to local mode immediately and start tracing the logs and make the property changes accordingly.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文