From the OpenID 2.0 specification:
URL Identifiers MUST then be further normalized by both following redirects when retrieving their content and finally applying the rules in Section 6 of RFC3986 to the final destination URL. This final URL MUST be noted by the Relying Party as the Claimed Identifier and be used when requesting authentication.
Redirects are not currently followed.
Alter the return value of hook_openid_discovery_method_info()
to include the new claimed identifier after following redirects, and use this value when available. See #12 for more information. Patch in #30 implements this change.
The current patch includes updated tests and hook documentation.
Evaluate the possibility of backporting this fix to D7 and D6. There is an API change in the expected return structure of a hook, so to make it backwards-compatible, D7 and D6 would need to add code checking for this structure and assign the list of services based on whether the new structure is used. If the return value from the hook has the keys 'services'
, it uses the new format, but if it returns a flat array of services, it uses the old format.
None.
The expected return value of hook_openid_discovery_method_info()
changes from a flat array of services to an associative array with the following structure.:
'services'
(required) an array of discovered services (including OpenID version, endpoint URI, etc).'claimed_id'
(optional) new claimed identifer, found by following HTTP redirects during the services discovery.From the OpenID 2.0 specification:
URL Identifiers MUST then be further normalized by both following redirects when retrieving their content and finally applying the rules in Section 6 of RFC3986 to the final destination URL. This final URL MUST be noted by the Relying Party as the Claimed Identifier and be used when requesting authentication.
Emphasis added.
I see no evidence for following redirects.
Fixed
7.0 ⚰️
openid.module
After being applied to the 7.x branch, it should be considered for backport to the 6.x branch. Note: This tag should generally remain even after the backport has been written, approved, and committed.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.