Can you enable access logging on CAS's app container, to see the URL
from the reverse proxy? Then you can see if the reverse proxy is
rewriting the protocol in the URL (even though it's URL-encoded).
On 2010-09-08 16:31 , bmaahs wrote:
Hello everyone
Currently I'm working with CAS and after a server architecture change, we're
experiencing a strange behaviour. I'm trying to narrow down the possible
causes of this behaviour.
In early development, we were accessing the CAS server directly by it's host
name or IP address. This worked fine.
The behavour appeared after we placed the CAS server behind a load balancer and
reverse proxy. So instead of accessing the CAS server via (example):
https://betaserver/cas/login?service=(http://beta.domain.com-encoded), it's
accessed through
https://beta.domain.com/cas/login?service=(http://beta.domain.com-encoded)
The behavour we are experiencing is that the scheme of the service URL being
passed into the login is being changed to https after the login occurs. Using
the example above, after login, the browser would be redirected to
https://beta.domain.com, rather than what was sent in the service parameter
(http://beta.domain.com).
Is there any code in CAS that could be doing this? My initial thought is "no",
since it was working fine when accessing the server directly, but I'm not sure. Has
anyone come across this issue before? Unfortunately, I don't have any clue how the
reverse proxy has been set up, as another department is handling that.
Any advice or direction would be greatly appreciated.
Thank you very much in advance.
Brant Maahs
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-dev
