Ticket #130 (reopened defect)

Opened 10 months ago

Last modified 3 months ago

associations fails when session type is implied no-encryption

Reported by: http://cgamesplay.com/id Assigned to:
Priority: minor Milestone:
Keywords: Cc: cgamesplay@cgamesplay.com
Project: php-openid OpenID Protocol: All versions
Series: 2.x.x Web Browser:

Description

If the library requests MyOpenID.com use a session_type of no-encryption, MyOpenID returns the mac_key but does not return the session_type. The fact that MyOpenID does this is against spec, however the library can deal with it, because mac_key is only sent when the session type is no-encryption.

Attachments

patch (0.9 kB) - added by http://cgamesplay.com/id on 02/16/08 11:52:43.
patch which allows gathering of session_type from mac_key.

Change History

02/16/08 11:52:43 changed by http://cgamesplay.com/id

  • attachment patch added.

patch which allows gathering of session_type from mac_key.

02/16/08 11:54:01 changed by http://cgamesplay.com/id

  • cc set to cgamesplay@cgamesplay.com.

02/18/08 13:29:30 changed by http://keturn.myopenid.com/

I'm a little baffled at how the installation at http://openidenabled.com/php-openid/trunk/examples/consumer/ does not run in to this.

02/18/08 13:39:25 changed by http://cgamesplay.com/id

If the association fails, it simply causes the library to function in "dumb" mode, requiring a verification request be sent to the server when the user completes authentication.

05/19/08 15:58:52 changed by http://cygnus.myopenid.com/

This requires some testing, since in server.py, AssociateRequest?.answer, we have 

        if not (self.session.session_type == 'no-encryption' and
                self.namespace == OPENID1_NS):
            # The session type "no-encryption" did not have a name
            # in OpenID v1, it was just omitted.
            response.fields.setArg(
                OPENID_NS, 'session_type', self.session.session_type)

05/28/08 16:34:22 changed by http://dag.myopenid.com/

  • keywords set to needs-investigation.

05/30/08 15:05:18 changed by http://dag.myopenid.com/

  • status changed from new to closed.
  • resolution set to fixed.

If this is still an issue for anyone, it's probably because the associate request is not recognized as an OpenID 2 request. Now the ruby and php code in AssociateRequest?.answer is the same as python's above.

05/30/08 15:05:37 changed by http://dag.myopenid.com/

  • keywords deleted.

09/09/08 18:30:12 changed by =arnott

  • status changed from closed to reopened.
  • resolution deleted.
  • protocol changed from OpenID 2.x to All versions.

What about if a V1 associate request comes in? The session_type MUST be included in the response even though its value is empty, per the v1 spec. Has this been fixed? I have reports that the PHP OpenID server omits the parameter incorrectly.