acslnienlim / marmoset

Automatically exported from code.google.com/p/marmoset
0 stars 0 forks source link

openid id field doesn't seem to be consistent for the same openid login #9

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
I have a server set up at http://cicada.cs.umd.edu:8080/

I had previously connected to it with my bill.pugh@gmail.com open id. Now, I'm 
trying to connect again, and it tells me that I have a uid of 
e2aab3126a841fc3fb2ab3f69996cee5f9892fb4, which wasn't been registered. But the 
database already has me registered with a uid of 
6da3210b85d616e0ea37d5941548dd10b79c7ab7. 

How do we know that these uid's are guaranteed to be invariant? How is it 
computed? 

Original issue reported on code.google.com by bill.p...@gmail.com on 23 Jan 2012 at 9:56

GoogleCodeExporter commented 8 years ago
They're computed by Google, and then we hash them. The identifier from google 
is computed partially based on the openid.realm param or the openid.return_to 
param if realm isn't found. So I think what we need to do is call setRealm() on 
the AuthRequest before sending it. It's possible that different return_to urls 
are causing the problem. Will look into this.

Original comment by rws...@gmail.com on 24 Jan 2012 at 1:52

GoogleCodeExporter commented 8 years ago

Original comment by rws...@gmail.com on 24 Jan 2012 at 1:52

GoogleCodeExporter commented 8 years ago
This should be fixed, see [1]. Addressed this in 2 ways:
1. More consistent realm, set per-request. Note that using different urls to 
access same submit server can still result in different IDs from google, which 
is addressed by
2. If the returned ID is from google, we use the email address instead of the 
OpenID as the user's id.

[1] 
http://code.google.com/p/marmoset/source/detail?r=c5ba1d43030fb0344e5723886de8e5
84e1389551

Original comment by rws...@gmail.com on 24 Jan 2012 at 3:29