Server http://www.myopenid.com/server responds that the ‘check_authentication’ call is not valid

[lancejpollard]

I have been working on this issue for the past few days and finally think I pinpointed the problem. A few other people seem to be having this problem:

• http://stackoverflow.com/questions/2917858/server-http-www-myopenid-com-server-responds-that-the-check-authentication-ca
• http://lists.openidenabled.com/pipermail/dev/2010-February/001528.html
  It boils down to this line where, if @store.nil?, it calls check_auth.

That call returns this...

#<OpenID::Consumer::FailureResponse:0x2217e04 @reference=nil, @endpoint=#<OpenID::OpenIDServiceEndpoint:0x225e944 @local_id="http://viatropos.myopenid.com/", @display_identifier=nil, @type_uris=["http://specs.openid.net/auth/2.0/signon", "http://openid.net/sreg/1.0", "http://openid.net/extensions/sreg/1.1", "http://schemas.openid.net/pape/policies/2007/06/phishing-resistant", "http://openid.net/srv/ax/1.0"], @used_yadis=true, @server_url="http://www.myopenid.com/server", @canonical_id=nil, @claimed_id="http://viatropos.myopenid.com/">, @message="Server http://www.myopenid.com/server responds that the 'check_authentication' call is not valid", @contact=nil>

That occurs in here:

def check_signature
    if @store.nil?
      assoc = nil
    else
      assoc = @store.get_association(server_url, fetch('assoc_handle'))
    end

    if assoc.nil?
      check_auth
    else
      if assoc.expires_in <= 0
        # XXX: It might be a good idea sometimes to re-start the
        # authentication with a new association. Doing it
        # automatically opens the possibility for
        # denial-of-service by a server that just returns expired
        # associations (or really short-lived associations)
        raise ProtocolError, "Association with #{server_url} expired"
      elsif !assoc.check_message_signature(@message)
        raise ProtocolError, "Bad signature in response from #{server_url}"
      end
    end
  end

If I add this to the config/environment.rb, it works fine:

OpenIdAuthentication.store = :file

Otherwise, with "none" or "in-memory" store, it doesn't work.

Any ideas?

This is on Rails 2.3.5

[nov]

Hi, I checked posted parameters and response body using this code.
http://gist.github.com/415407

It seems ruby-openid is working correctly.

Plus, I tried to login using several OPs without stored associations.
(every time, I removed stored associations in DB/tmp file etc.)
As the result, actually check_authentication request failed between several OPs, but not all OPs.

Failed

• Yahoo!
• MyOpenID
• 1id.com

Succeeded

• Google
• MySpace

I'm not sure what's the cause, but it might be on OP side.
I hope JanRain guys take a look at this issue.
They can check why MyOpenID.com returns is_valid:false response.

[lancejpollard]

Perfect, looking forward to the fix.

[bandito]

We have the same issue.

This is not an actual solution but if you comment out line 125 of CheckIDRequest

124         if @assoc
125           #message.set_arg(OPENID_NS, 'assoc_handle', @assoc.handle)
126           assoc_log_msg = "with assocication #{@assoc.handle}"
127         else
128           assoc_log_msg = 'using stateless mode.'
129         end

It works for Google and Yahoo. Waiting for a fix :)

[augustl]

Just chiming in. Having this issue as well.

[ku1ik]

I am also experiencing this issue. I see this problem randomly, most of requests are failing, only few percentage of them is successful.

[ku1ik]

Guys, I think I know what's the problem. ruby-openid is working fine.

If you are using memory store, there's separate store for each mongrel/passenger/thin/unicorn process. In most cases you have more than 1 process handling requests. If it happens that two openid requests are handled by 2 different processes then it will fails because second process doesn't have data which was stored in store of 1st process. In this case you should always use file or memcache store.

So it looks like this issue is invalid.

[bandito]

@sickill Νope, I'm using filestore and a single mongrel anyway.

[ku1ik]

Damn.

[nov]

unfortunately, it was DB store in my case.

[insane-dreamer]

I had the same problem, setting OpenIdAuthentication.store = :file resolved the issue.

[ysth]

This is a myopenid bug; it should work when the relying party no longer has the stored association and has to make a check_authentication direct verification request. But it doesn't, because myopenid is including mode in the signed parameters, and the check_authentication message has the mode changed from id_res to check_authentication.

The only workaround is to try to reduce how often check_authentication is resorted to. But by design, sometimes it will be needed, and myopenid won't work.

[changemewtf]

I'm still seeing this issue. Is there a resolution for this now, or is it just something we'll have to deal with?

[ysth]

I believe so; if you can find a way to report a bug on myopenid, please do; as is, a relying party with no cache capability can't authenticate their openids at all, which majorly sucks.

[changemewtf]

@nov's post above indicates issues with Yahoo! and 1id.com as well. I also get this issue with LiveJournal. Is this something that each provider has to fix on their end?

Also, am I correct in understanding that changing the store to something more persistent than in-memory is a potential workaround because it decreases the likelihood an additional verification request (which will inevitably fail) must be made?

[ku1ik]

@mcantor: Yes, for me switching to filesystem store solved the issue.