openid
Server responds that the 'check_authentication' call is not valid
We started having this issue crop up and now it's affect a large percentage of our openid log ins.
#<OpenID::Consumer::FailureResponse:0x007f84a00418f8 @endpoint=nil, @message="Server https://www.google.com/a/shopify.com/o8/ud?be=o8 responds that the 'check_authentication' call is not valid", @contact=nil, @reference=nil>
I've been able to reproduce it on our staging environment so I threw in some logging of the requests and responses. Here is the request that's failing:
#<OpenID::Message:0x007f2f770bd648 @args={["http://specs.openid.net/auth/2.0", "mode"]=>"check_authentication", ["http://specs.openid.net/auth/2.0", "op_endpoint"]=>"https://www.google.com/a/shopify.com/o8/ud?be=o8", ["http://specs.openid.net/auth/2.0", "response_nonce"]=>"2014-09-24T22:01:47ZWQC4oCngG0MFlA", ["http://specs.openid.net/auth/2.0", "return_to"]=>"https://foggy-meerkat-builders-3.staging.shopify.com/admin/staff", ["http://specs.openid.net/auth/2.0", "assoc_handle"]=>"1.AMlYA9W7SJ96LV7ncVuuTOziqdBbwOw5svD1SPykJqM43wirWRb-nRY4HyRM1JzD", ["http://specs.openid.net/auth/2.0", "signed"]=>"op_endpoint,claimed_id,identity,return_to,response_nonce,assoc_handle,ns.ext1,ext1.mode,ext1.type.ext1,ext1.value.ext1,ext1.type.ext2,ext1.value.ext2,ext1.type.ext0,ext1.value.ext0", ["http://specs.openid.net/auth/2.0", "sig"]=>"fWa64GHxywaDukzfsHRhwcuYF6c=", ["http://specs.openid.net/auth/2.0", "identity"]=>"http://shopify.com/openid?id=113240996681813919788", ["http://specs.openid.net/auth/2.0", "claimed_id"]=>"http://shopify.com/openid?id=113240996681813919788", ["http://openid.net/srv/ax/1.0", "mode"]=>"fetch_response", ["http://openid.net/srv/ax/1.0", "type.ext1"]=>"http://axschema.org/namePerson/first", ["http://openid.net/srv/ax/1.0", "value.ext1"]=>"Samuel", ["http://openid.net/srv/ax/1.0", "type.ext2"]=>"http://axschema.org/namePerson/last", ["http://openid.net/srv/ax/1.0", "value.ext2"]=>"Kadolph", ["http://openid.net/srv/ax/1.0", "type.ext0"]=>"http://axschema.org/contact/email", ["http://openid.net/srv/ax/1.0", "value.ext0"]=>"[email protected]"}, @namespaces=#<OpenID::NamespaceMap:0x007f2f770c2440 @alias_to_namespace={:null_namespace=>"http://specs.openid.net/auth/2.0", "ext1"=>"http://openid.net/srv/ax/1.0"}, @namespace_to_alias={"http://specs.openid.net/auth/2.0"=>:null_namespace, "http://openid.net/srv/ax/1.0"=>"ext1"}, @implicit_namespaces=[]>, @openid_ns_uri="http://specs.openid.net/auth/2.0">
And the response from Google:
#<OpenID::Message:0x007f2f77140c28 @args={["http://specs.openid.net/auth/2.0", "is_valid"]=>"false"}, @namespaces=#<OpenID::NamespaceMap:0x007f2f77140bd8 @alias_to_namespace={:null_namespace=>"http://specs.openid.net/auth/2.0"}, @namespace_to_alias={"http://specs.openid.net/auth/2.0"=>:null_namespace}, @implicit_namespaces=[]>, @openid_ns_uri="http://specs.openid.net/auth/2.0">
As far as I can tell we haven't changed anything so it might be an issue with Google.
We have a user in our application experiencing this same issue. So far as I can tell it's only the single user.
We're using an internal provider.
Using 2.7 version of the gem.
As a follow up to my previous comment, here is the result of some investigation from one of our teams:
"For those curious, the issue arises due to non-standard handling of the x-www-form-urlencoded media type in both Apache Tomcat (our webserver) and the Apache HTTP client library used by openid4java (the typical Java client library for OpenID 2). This media type does not permit any parameters, but the client library is adding one anyway, sending "application/x-www-form-urlencoded; charset=UTF-8". Our web server also follows non-standard behavior by accepting and using the character encoding specified in that header, leading to Java applications functioning correctly. In contrast, the Ruby OpenID gem is sending the raw (spec-complaint) header value of "x-www-form-urlencoded", which exposes the poor behavior of our server."
I was struggling to figure out why some of our Ruby applications were exhibiting this issue with specific users but those same users could log into other applications. Hopefully this helps others that run into the same problem.
In our case the team that did the investigation is going to fix it on the server side, but if that isn't an option for others (maybe you don't have any access or control over the provider) then you might be able to add the non-standard headers to mimic the Java client behavior.
