You are here

Redirect loop on login page

Submitted by tbird on Fri, 09/05/2008 - 16:48

Once in a while one of us gets a redirect loop on our Luminis login page. There are maybe ten of us using it and it occurs once every few weeks. This time it happened for me after Firefox crashed and restarted. If I clear the cookies it will stop looping.

We use SSL. That may be a clue.

Here are the headers for the first page it goes to (edited for privacy):

GET /cp/home/displaylogin HTTP/1.1
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/2008070208 Firefox/3.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: __utma=118811218.88382888.1218888818.1218888818.1218888818.1; __utmz=118811218.1218888818.1.1.utmccn=(direct)|utmcsr=(direct)|utmcmd=(none); CFID=83228188; CFTOKEN=28881488; CFCLIENT_COLLEGE=browseback%3D1184%23lastid%3D1184%23os%3DWin%23browsercode%3DN%23user%8Fagent%3DMozilla%2F8%2E8%28%28Windows%3B%28U%3B%28Windows%28NT%288%2E1%3B%28en%2DUS%3B%28rv%3A1%2E8%2E8%2E1%28%28Gecko%2F2888888288%28Firefox%2F3%2E8%2E1%23versioncode%3D8%23testcookies%3Dblank%23; CFGLOBALS=urltoken%3DCFID%23%3D83228188%28CFTOKEN%23%3D28881488%28jsessionid%23%3D843828a3388811288a8c%23lastvisit%3D%8Bts%28%282888%2D88%2D28%2814%3A14%3A48%28%8D%23timecreated%3D%8Bts%28%282888%2D88%2D21%2811%3A43%3A82%28%8D%23hitcount%3D1%23cftoken%3D2888188%23cfid%3D8328188%23; runId=84343488888381813; fos.web.server=; iPlanetDirectory-ims=gwMjqR1k; UserAgentId=38848388241888888; JSESSIONID=8D88F4B88228ED83A88A288AFFEF2D4; badprotocol=1

HTTP/1.x 302 Moved Temporarily
Server: Apache-Coyote/1.1
Set-Cookie: badprotocol=2;; Path=/
Content-Type: text/html;charset=UTF-8
Content-Length: 0
Date: Fri, 05 Sep 2008 13:58:19 GMT

It keeps redirecting to the above url about 10 times in less than a second. Then it goes once to:

Then once to:

Then once to:

Then once to:

Then once to:

Then the loop starts over from the beginning, where it goes to:
and loops on that url 10 times again...

Has anyone else experienced this? Any ideas what will prevent it?



Luminis Version:

were seeing this too - did you ever get to the bottom of this ?

I opened an SR with Sungard (SR #: 1-240456751). They could not reproduce it. It only happened to me after Firefox crashed. After restarting Firefox and also restarting Luminis, which I had to do for other reasons, I cannot reproduce it now either. But, I'm confident it will reappear sometime.

If you can reproduce it, I hope you will tell Sungard.


We also have an open SR 1-299743941

The steps I posted to reproduce:

I resolve the broswer/cookie problem by manually removing all cookies.

Then visiting presents the log in screen

Steps to make the loop happen again:
1) close FF3
2) open FF3
3) open a new tab,
4) log in with the credentials supplied
5) close FF3, press the Save & Quit button (note that I did not log out of the Portal)

6) open FF3, no dialogue box is given, but the tab starts in the infinite loop state.


we have what appears to be the same issue in in addition to your description, in the cp.log, there are a large number of messages that correlate to this loop:

[2009-03-05 16:30:37,926] [ERROR]( {http-80-Processor23} [com.pipeline.web.SecureRedirector]:
Access security violation:[
GET /cp/home/displaylogin
Mode: insecure

this by no means affects everyone. so far, we have not been able to isolate a chain of events that creates this issue. out of dozens of logins, i personally have experienced it once.

we have three web servers in our PD environment. on a single web server, we have seen rates for this message as high as >750 per minute.

sungard has taken this as a defect and is looking into it.

We get the same behavior and have seen more reports from users as of late. You can recreate the problem by removing all but four cookies (related to your luminis platform): fos.web.server, runId, cookies, and UserAgentId. With those four remaining, you should get the loop (I use the Add and Edit Cookies extension for Firefox).

We are in a pd environment ( and also get the "access security violation" errors. In fact, they basically litter our cp log files. When I looked at the headers during one of these loops. I also noticed that it redirects to cp/home/displaylogin 11 times. According to 1-3NYOQW from SunGard, "The SecureRedirector class will allow up to ten (10) redirections before killing the user's session."

So it seems to me that on the 11th try, it fails and brings you right back to the originating page. I started working on something to clear out those four remaining cookies automatically, or at least fos.web.server and runid, but with no luck yet.


I was able to resolve the problem. The loop does seem to be closely related to the SecureRedirector, and the Access security violation errors in cp.log appear during one of these loops. It's not really a cookie handling problem as I originally thought. Not sure if all of the errors are caused be this, but it makes sense that they would be.

There is a property file called It is in the jar $CP_WEBINF/lib/cp.jar. Extract the file com/pipeline/web/ and look for the line:

Change it to false, update the jar with the new file, and restart the webserver. No more loop. I also wanted to do a little more testing to make sure the change doesn't compromise security (on the login page, SSO to BSS, etc.). I've only done this in our test environment so far. I guess we can wait to see if Sungard releases an "official" fix for this.

Any updates on this redirect loop problem? We're upgrading to Luminis 4 soon and I have been experiencing this problem on our test system.

Did anyone implement the fix in a production environment or know if sungard came out with a fix of their own? I can't seem to find the related defect on the UDC support site.




Because of the way the security, unenforcedURI, delegators, etc. work (including the need to alter the internals of jars), and because of the pages that we require to be over SSL - we do not think that this is the best solution.

However, I think that it would be possible to update


If the referer is a certain value, it could send a delete cookie (or set cookie to blank and expired)

and also redirect to the log in page.


University of Leeds, UK

p.s. I will try and do this soon, but I am catching up on a backlog

Any update on this? Did you try the solution you mentioned? We have the same problem and are looking through solutions.


Biola University

Since the issue is fixed by removing cookies, we chose to do this manually. This javascript code is executed when a user hits the serverFailure.jsp page.

function clearCookie(name, domain, path){
var domain = domain || document.domain;
var now = new Date();
var expirationDate = new Date();
var path = path || "/";
expirationDate.setDate(now.getDate() - 7);
document.cookie = name + "=; expires=" + expirationDate.toUTCString() + "; domain=" + domain + "; path=" + path;

The root cause appeared to be the cookes being put in two locations in the FQDN and were, therefore, being sent twice.

For example, the __utma cookie was being put in and When a user goes to, the __utma cookie that is store in and the __utma cookie that is store in are sent to the page request.

The __utm[abcz] cookies are part of Google Analytics. I have no idea why these tripped up the screen so badly.

After adding this javascript, the pageviews of our serverFailure.jsp page views went down by 85%.


We have recently started experiencing the redirect loop issue and are looking a resolution. Has anyone been able to find a solid fix to prevent the loop?

Solano Community College