We used two Drupal installations (Provider and Consumer) to track and analyse a OpenID Login process.
While doing this, we've seen that the Consumer sent a HTTP Authentication Basic Header to the OpenID Provider. This is because the OpenID Identity "user@domain" was passed to http://api.drupal.org/api/function/drupal_http_request/7, and parse_url() then thinks that "user" is a HTTP Authentication username.
This is does not break functionality nor is it a security issue, because no confidental information is published (the OpenID Identity is public), however, the spec says that the Consumer should normalize a OpenID Identity. Also, it is unlikely, but a Provider could for some reason block HTTP requests with Basic Authentication headers and this would break the discovery process.
I'll try to write a patch soon.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | 472292.openid_remove_user.patch | 1.17 KB | berdir |
Comments
Comment #1
berdirThe attached patch fixes the described issue.
While creating the patch, I noticed that there are no tests for "user@example.org" OpenID Identities...
Comment #2
c960657 commentedThe standard's description of the normalization process does not mention removal of usernames. Though probably very unusual, I wonder whether identifiers of the form http://john:secret@example.com are expected to work, i.e. whether Relying Parties should send the credentials along?
Comment #4
heine commentedThis behaviour is according to spec (http://openid.net/specs/openid-authentication-2_0.html, see 7.2).