login process gets stuck in loop

[Stuart Metcalfe]

Barry Warsaw said:

If you go to http://edge.launchpad.net/~private-canonical-dx-commits
you'll see that that team has a mailing list and an archive. If you
click on the archive link, it should take you to
http://lists.launchpad.net/private-canonical-dx-commits
  but since that's a private team, you need to go through the openid
dance before you can have access to it. Actually, you're not a member
of the team, so you'll probably get a 404 when you try to access it;
we need to get Kiko to make you a member of that team.

Anyway, the apache-openid module is supposed to handle this case by
asking Launchpad if you're a team member, and if so, you get
authorized to view the archive. However, you'll often end up in an
openid dance loop from which you cannot escape. Well, actually I have
by doing the following:

* fire up opera (or any web browser?)
* clear all launchpad cookies
* restart the browser
* hit the page

Then the expected happens. You go through openid with redirects and
end up in the archive. I just tried this with Opera and it works.
There are no messages in the archive, but I can still see the
directory listing so I know it's working.

We really need to fix this. My suspicion all along has been that
session management in the apache-openid module is the root cause,
which makes sense I think because blowing away your cookies and
restarting gets you a new session.

[Stuart Metcalfe (stuartmetcalfe)]

Changing importance to medium. This bug negatively affects the user-experience on (potentially) a number of important systems but is relative rare and can be worked around by the user.

[Stuart Metcalfe (stuartmetcalfe)]

I've agreed that we'll devote one developer for a 1/2 day to attempt to diagnose this. If we can't reproduce it reliably then we'll instead hope to fix it as a side-effect of a number of improvements we need to make in future releases of this project.

[Stuart Metcalfe (stuartmetcalfe)]

It looks like there are a few issues which may be contributing to this bug:

1. On logout, apache openid redirects you to the login page. When combined with our use of automatic redirection on the openid server, this means that you're immediately logged back in again, creating a loop. We recently added a configuration option for a custom logged-out url which can be outside the openid and protected dirs. This breaks the logout/in/out/in loop. IS should already have this code packaged somewhere.

2. Being denied access to a resource based on team membership doesn't log you out, it keeps you logged in. I've filed bug #449425 to cover this.

3. Because apache-openid doesn't sit over the top of the protected resource but is rather served from a separate path (usually /openid/), it's possible for the module to 'forget' where it was supposed to be directing you. A better solution might be to actually serve the openid request from a sub-path of the requested url (eg: /path-I-want/openid/login) but this will require some further investigation, consideration of potential pitfalls and, most likely, a fair amount of apache wizardry.

[Stuart Metcalfe (stuartmetcalfe)]

Marking as incomplete. We need to understand how easy (or not) it would be to make apache-openid behave as described in item 3 above, and if that is a sensible approach.

[Stuart Metcalfe (stuartmetcalfe)]

This doesn't help matters either:

4. If I'm logged in and I *do* somehow end up stuck on the /openid/login page, I'm shown a 'continue' button. This is somewhat misleading as all it does is attempt to log me in again. The only option I should have, if I'm logged in and the page doesn't know what resource I'm attempting to access, is a 'logout' button. Filed as bug #449441.

[Stuart Metcalfe (stuartmetcalfe)]

We did a major refactor of this code, to be released under the 2.x series. It's currently going through QA and, pending QA's approval, will be rolled out to all sites currently using the old code. We'll need to confirm in testing but I believe the new release will address this bug.

As it would be rather imprudent to roll brand new code out to a high volume public site, it'll get a little time on some less demanding sites first. We'll be in touch about rolling out to lists.lp once we're confident it won't break stuff :)