OpenID problem with stackoverflow.com

[Ian Warford]

Attempting to use my lp openid on stackoverflow nets this error:

Unable to log in with your OpenID provider:
OpenID parameter 'session_type' was missing from the query.

Used my lp URL: https://launchpad.net/~iwarford

Now, this may be an issue with the openid client libraries they're using, or it may be an issue with your server implementation. I'm not sure.

I think this is an issue with your server protocol, though -- apparently that option is optional in OpenID 2.0, and that's what the client that stackoverflow is using? It looks like the people responsible for OpenID didn't think about how it would break when they change protocol versions.

Anyway, I don't know if it'll be fixed on the client end or the server end first, but you have been so notified.

[Ryan Ahearn (ryan-c-ahearn)]

I am having this same problem. I also opened a bug with the people behind stackoverflow.com, but they seem to think it's a server issue.

The error occurs before I am ever transferred to launchpad to verify that I want to continue. I was able to sign into stackoverflow several weeks (I think) ago, but now I consistently get this error.

[Stuart Bishop (stub)]

The session_type request parameter was optional in OpenID 1.1, defaulting to no encryption. It no longer appears to be optional in OpenID 2.0. This is not explicitly stated. I suspect this is a bug in the Janrain Python libraries we are using, or possibly in our use of them.

This seems to be a common issue on providers - the AOL provider also seems to be affecting Stack Overflow (http://stackoverflow.uservoice.com/pages/general/suggestions/21561-openid-error-session-type-missing- ). I expect this means consumers will need to cope with this parameter missing even if it isn't quite per spec.

[Stuart Bishop (stub)]

I'm probably not doing this write (its been a while since I poked around here...), but I can't get session_type set in the openid response:

>>> postargs = {'openid.return_to': 'Neverland', 'openid.ns': 'http://specs.openid.net/auth/2.0', 'openid.claimed_id': 'http://bogus.example.invalid:port/', 'openid.mode': 'checkid_setup', 'openid.session_type': 'no-encryption', 'openid.identity': 'http://bogus.example.invalid:port/', 'openid.assoc_handle': 'FLUB'}
>>> message = Message.fromPostArgs(postargs)
>>> request = AssociateRequest.fromMessage(message)
>>> a = Association('handle','secret', 123456789, 999,'HMAC-SHA1')
>>> response = request.answer(a)
>>> response.encodeToKVForm()
'assoc_handle:handle\nassoc_type:HMAC-SHA1\nexpires_in:0\nmac_key:c2VjcmV0\nns:http://specs.openid.net/auth/2.0\n'

[Andrew Arnott (andrewarnott)]

Stuart, the session_type parameter never appears in a checkid_setup message as you're trying to do here. It is only in the associate request message and its response. And since it is the direct response that is missing it the parameter, it won't actually have the 'openid.' prefix. It will be just 'session_type' as the parameter name.

[Andrew Arnott (andrewarnott)]

Stackoverflow is using the dotnetopenid library, so all relying parties that use this library are affected. Thanks for working on this at the server end so that all RPs start working implicitly.

If this is a bug in the Python libraries I'd like to see this followed up with the library author so that all Providers get this fix. I agree that the 2.0 spec could have called more attention to the change that it is no longer an optional parameter so that libraries wouldn't get this wrong so much. Hopefully 2.1 can fix that in the spec.

[Andrew Arnott (andrewarnott)]

I just downloaded Janrain's Python library. It looks like the latest version of the server does send session_type back as it should, and the relying party component even enforces this behavior as DotNetOpenId does. So modern Python RPs should be failing against launchpad.net as well.

[Francis J. Lacoste (flacoste)]

We have an open bug about upgrading the python-openid library: bug 318972.

[Andrew Arnott (andrewarnott)]

Francis, this IS bug 318972.

[Andrew Arnott (andrewarnott)]

It looks like bug 297816 is the one you were referring to, Francis.

[Christian Reis (kiko)]

Bumping to high as this keeps on buzzing in my ear..

[Francis J. Lacoste (flacoste)]

Fixed in RF 7818. I tested that I could logged in on stackoverflow using staging. This will be deployed on Wednesday.

[Ryan Ahearn (ryan-c-ahearn)]

This has been working for a long time.