Creating a launchpad account in the process of an OpenID authentication returns a failure to the RP

[Christopher Armstrong Test 1]

To reproduce:

(Log out of launchpad)

1. Go to staging.landscape.canonical.com
2. Click "I don't have an account yet"
3. Click "login or create a Launchpad account"
4. Enter a unique email address
5. Select "No, I want to create an account now"
6. click "Continue"
7. Wait for email, click it
8. Fill out resulting form and submit it

You'll be redirected back to Landscape and see "Launchpad authentication failed". The account is created Launchpad-side, but we're not getting the proper response from the OpenID request. If you then go through the same process but log in with your newly-created user it'll work.

[Andreas Hasenack (ahasenack)]

... it will work indeed, but you will have to fill in the form in Landscape with your email again.

[Andreas Hasenack (ahasenack)]

This is very messy for Landscape.

Let's say you get to the part of the error. Then you just try again to login on Landscape using that email. What happens now? *Landscape* will prompt you for a password. But the user was never created on the Landscape side, so there is no password that will work. And if the person requests to have the password sent to the email, Landscape will say it did so, but of course nothing was sent (the account doesn't exist: LS says it sent the email to avoid phishing for valid logins).

The same happens when accepting an invitation to join Landscape, which is the most frequent way to get new accounts/logins in Landscape.

[Christopher Armstrong (radix)]

Data points:
- It doesn't matter if I specify the max_auth_age in a PAPE extension
- It doesn't matter if I check the "hide my email address from other Launchpad users" checkbox

[Christopher Armstrong (radix)]

Here's the status object we're getting back from consumer.complete():

<openid.consumer.consumer.FailureResponse id=None message='HTTP Response status from identity URL host is not 200. Got status 404'>

I checked out my identity URL page.

https://login.staging.launchpad.net/+id/NePyJH3

It renders "OpenID Identity URL for Christopher Armstrong Test 7" in a browser, but using 'wget' shows that it's a 404. Could this be the problem?

[Christopher Armstrong (radix)]

actually, that URL started 200ing shortly after -- after some discussion with the LP devs, it appears to be a problem related to the replication. The request is going to the replication slave, but the data (the brand new account) hasn't been replicated yet, so we're getting a 404.

[Francis J. Lacoste (flacoste)]

Given stub's fix to bug 311690 that is available on both production and staging, I don't see how this happening.

We talked in the past of always using the MASTER_FLAVOR for the OpenID site. Stuart if you don't see any obvious reason explaining this, we could simply use the MasterDatabasePolicy for the OpenID site.

[Francis J. Lacoste (flacoste)]

Putting as Critical since this probably also affects the Shop and other Account creation. Weird that nobody reported a problem apart Landscape though...

[Stuart Bishop (stub)]

Bug 311690 changed things so 404s will never be raised if the SLAVE_FLAVOR has been selected as default, instead causing the request to be retried using the MASTER_FLAVOR.

I've confirmed locally that this behavior is working for the identity URLs.

I've confirmed that the account creation workflow works with 3rd party OpenID 2 consumers (Livejournal tested).

What seems to be failing is some sanity checks being done after successful authentication has been reported.

What I don't know yet is what these sanity checks are. The error message reported by Christopher suggests the consumer library is attempting to retrieve the identity URL, but I haven't confirmed this yet. The 404 may be generated because no account exists with that openid_identifier yet, or it may be we are accessing the wrong page (eg. the referrer URL which is probably the token validation, which will 404 the second time it is accessed because the token is already consumed).

I am seeing caching weirdness, both testing against staging locally and from devpad. We seem to be caching anonymous requests to login.launchpad.net, including the 404 responses. If something accesses the identity URL before the workflow is complete and the account exists, then that 404 sticks for quite some time. I don't think this directly relates to this bug, apart from making testing a pain.

[Stuart Bishop (stub)]

Further testing is indicating that the Bug 311690 fix is not working as it should for identity URLs. It is working for other URLs however.

[Stuart Bishop (stub)]

This isn't a replication bug, it is an 'icky traversal/publishing bug.

The attempt to retry the request is working as it should. The first part of the Retry handling is to call request.retry() to build a copy of the request. This copy isn't good. In particular, request.getURL() returns just 'http://login.launchpad.net' instead of 'https://..../+id/foo' as both the application root and traversed path segments are not being set. This causes the OpenID provider to respond as if someone requested authentication of an invalid OpenID identity.

We can work around it as suggested by forcing the use of the master database as suggested earlier. However, it will still fail occasionally as Retry handling is broken for code that relies on getURL() - we see this sometimes in normal operation due to the deadlock and serialization exception handling. It will also cause hard to reproduce bugs elsewhere as they will only appear in the rare case a request needed to be retried.

[Stuart Bishop (stub)]

To trigger this bug, set your _slave db connections to 'launchpad_empty' instead of 'launchpad_dev'. This will cause all lookups in the db to fail, triggering the retry-on-master behavior.

The patch adds an assert at the point things go wrong.

[Andreas Hasenack (ahasenack)]

Another data point. I just tried an account creation through wiki.ubuntu.com and got back this error:

"OpenID error: HTTP Response status from identity URL host is not 200. Got status 404."

Attached section of a screenshot.

[Francis J. Lacoste (flacoste)]

The problem is only in the protocol part (http vs https). At the place you put your assertion, it's normal that the path is missing. getURL() returns the URL based on what as been traversed so far. The port is lost because we set the port based in the request factory which isn't used for the retry.

I'll modify the request factory to set the proper request env var so that getURL() always work with https.

[Francis J. Lacoste (flacoste)]

Fixed in RF 7588.

[Francis J. Lacoste (flacoste)]

That was cherry picked this week.

[Andreas Hasenack (ahasenack)]

Marking as invalid in Landscape.