I have an interesting situation where
Notice something and somethingelse are repeated in the TARGET
Has anybody seen this issue before?
I suspect the request might have gone in loop before redirected to the login server.
Capture the HTTP header trace and confirm if that's the case.
This behavior is typically seen when one has a custom login page in front of login.fcc and the custom login page has decode and encode functions.
Do you have any custom logic that decodes and encodes URL at the Login Server OR is it just pure OOB login.fcc.
If you have custom code logic that decodes and encodes the URL; then you need to enhance the code logic to handle failed login redirects (As these redirects append URL encoded Target, within Target - hence you need to do a double decode before you get the final Target).
There is no custom login form. The authscheme is something like blah.blah.com/login.jsp
So I get a 302 (redirect to login.jsp) with the TARGET shown above.
One thing we discovered today is the apache is version 2.4.10 and it works fine with webagent 12.0 SP3, but does not with webagent 12.52 SP1 CR1.
When things don't work right, the trace file shows that the webagent is actually receiving
therefore, the TARGET is wrong.
It seems to be a combination of Apache 2.4.10 and WebAgent 12.52 SP1 CR1 issue.
It could be an issue. However unless we investigate the browser traces and webagent trace logs, it would be difficult to predict.
The login.jsp is a Custom login page as far as CA SSO is concerned. This is not the OOB login page that is shipped with the product. Do we know what code logic is present within the login.jsp as far as CA SSO functional aspects are concerned (e.g. does the login.jsp only read key values and does a post to login.fcc OR does it have any other logic).
We also need to nail the exact User Journey which is causing this e.g. User access protected page, enters incorrect credentials first time, again enters incorrect creds second time, then enters correct credentials on third attempt and we see this behavior.
Have we compared Agent Configuration Object parameters for both versions of WebAgent.
The login.jsp does not come into play at all. Apache receives a request for /test.html?something=1&somethingelse=2
The webagent gets the request as /test.html?something=1&somethingelse=2&something=1&somethingelse=2
and redirects to what the authscheme has specified with encoded TARGET.
We used exact same policy servers for both versions of the agent. So the ACO's are identical.
I think Apache and the WebAgent are at fault. I will try to reconstruct at home and I am sure login page makes no difference what the TARGET ends up being. I will post my findings.
Something external factor has to construct the URL in that form, hence when investigating please check this too what is causing the URL to be formed in this state.
RE: How the SiteMinder Webagent encode & decode URLs
A WebAgent always encodes the TARGET when redirecting to Login Page OR to Cookie Provider. If there are multiple failures, the TARGET gets double encoded, OR Triple encoded. It is just based off the User Action and Journey to begin with. Thereafter the LoginPage/LoginServer (WebAgent Version), CookieProvider (WebAgent Version) and TargetServer (Apache Server WebAgent Version) play a important role. Further more things like LegacyEncoding, FCCCompateMode in ACO Parameters OR difference in Framework / Traditional Agents play a crucial role here.
Hence trying to ascertain the complete User Journey & Components involved in the interaction, is key to understanding this behavior.
OK here is more information. This specific apache is a acting as a forward proxy. So the problem shows up when it is used as a proxy for the browsers. We have been able to reproduce the problem now and have given CA support all the information. I'll post the answer, when we know it.
Thanks to those who replied here. Appreciate it very much.
Just a quick update. The issue is found and CA engineering has provided a fix in libmod_sm24.so.