On Sun, Jun 7, 2009 at 3:21 AM, stackoverflow
more info here:
I have confirmed that the https://login.launchpad.net/+openid
OP endpoint is
sending the session_type parameter back in the associate direct response
This OP seems to implement OpenID 2.0 (it sends the 'ns' parameter back),
2.0 mandates that session_type is NOT an optional parameter. In OpenID 1.x,
an optional parameter. This is a common bug for OPs and I will talk to
about getting this bug fixed on their end.
1.1 spec: http://openid.net/specs/openid-authentication-1_1.html#anchor14
2.0 spec: http://openid.net/specs/openid-authentication-2_0.html#anchor20
I set up an instance of our OpenID provider so I can test on my local
machine, but the StackOverflow login doesn't even get as far as it
does with the operational instance. It just fails with a web request
Compare the results of trying to log into StackOverflow from my test
instance URL with the results from the operational instance URL.
Could this be because I'm using a non-standard port number on the test
instance? It seems to be set up correctly because I can log into
ThinkWiki, for example on both the test and operational instances.