OpenID realm is language dependent [#751578]

Posted by Gábor Hojtsy on March 24, 2010 at 12:21pm

8 followers

Issue Summary

Because the openid.realm is generated as

<?php
 url('', array('absolute' => TRUE)); 
?>

, the realm will different depending on which language page I'm on. On a default language page it will be http://example.com/ while on a Hungarian page, it will be http://example.com/hu if language path switching is turned on.

What this means is that the relying party will need to maintain multiple records for this site, since it will report different URLs based on which language page I was on.

My initial suggestion is to always use the default language to formulate the OpenID realm. This might however not be good for cases when domains play a part in language negotiation. Or better said, it is just a matter of perception. The same user on different domains showing the same site would probably equally be eligible to use his OpenID, so providing the default site root (without language affecting it) is the best as OpenID realm IMHO.

Attachment	Size	Status	Test result	Operations
openid-language.patch	598 bytes	Idle	PASSED: [[SimpleTest]]: [MySQL] 19,164 pass(es).	View details

Comments

#1

Posted by Gábor Hojtsy on April 12, 2010 at 10:43am

In fact, if you have the default language set, the language will be included even in this case in the URL. I think we can just skip using url() and use $base_url directly.

Attachment	Size	Status	Test result	Operations
openid-language.patch	1.12 KB	Idle	PASSED: [[SimpleTest]]: [MySQL] 19,163 pass(es).	View details

#2

Posted by alexanderpas on April 12, 2010 at 10:53pm

Status:

active

» needs review

I agree that using $base_url seems to be the best approach.

(I wonder why the test status is "Ignored")

#3

Posted by c960657 on April 22, 2010 at 8:21pm

+ $request['openid.realm'] = $base_url .'/';

Why add a trailing slash?

#4

Posted by Gábor Hojtsy on April 23, 2010 at 6:11am

It is how url() would have generated this before the patch (if without language URL mangling), so for backwards compatibility. Ie. if you already have an association with this URL on another provider, we should send the same URL going forward.

#6

Posted by c960657 on April 26, 2010 at 9:05pm

Status:

needs review

» reviewed & tested by the community

Sounds reasonable.

#7

Posted by Dries on April 27, 2010 at 10:31am

Status:

reviewed & tested by the community

» fixed

Committed to CVS HEAD. Thanks.

#8

Posted by System Message on May 11, 2010 at 10:40am

Status:

fixed

» closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

#9

Posted by guillaumev on November 11, 2010 at 4:53pm

Hi,

Is this going to be fixed on Drupal 6 as well or is it just for Drupal 7 ?

Thank you.

#10

Posted by xamanu on November 10, 2011 at 12:16am

Version:	7.x-dev	» 6.x-dev
Status:	closed (fixed)	» needs review

Backport for Drupal 6. Since this is a bug it would be nice to have it commited to Drupal 6.

Attachment	Size	Status	Test result	Operations
openid-language-6.patch	912 bytes	Idle	PASSED: [[SimpleTest]]: [MySQL] 190 pass(es).	View details

#11

Posted by xamanu on November 10, 2011 at 12:39am

Uploading patch that works fine with drush make

Attachment	Size	Status	Test result	Operations
openid-language-d6_751578_10.patch	904 bytes	Idle	FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch openid-language-d6_751578_10.patch. Unable to apply patch. See the log in the details link for more information.	View details