Possible namespace bug
| Project: | OpenID Provider |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | won't fix |
Jump to:
James, when I try to hit a D6 instance running this module from a Moodle instance running 1.9.2 and the OpenID plugin (using the OpenID SSO option), I get an error back saying server denied check_authentication. It looks like perhaps the root cause is that Moodle's OpenID client looks for a namespace named "OpenID namespace" in the message it gets from your provider, but does not find it. This string is defined in the lib/openid/auth/OpenID/Message.php file in the Moodle plugin as the value for the Auth_OpenID_OPENID_NS constant.
Perhaps a bit more relevantly to your code, here is the var_dump() of the message Moodle got from the provider URL right before it died, and in which it was looking for the above mentioned namespace string:
_idResCheckSignatureserver_url = http://localhost:7064/openid/provider
message = object(Auth_OpenID_Message)#381 (4) {
["allowed_openid_namespaces"]=>
array(2) {
[0]=>
string(28) "http://openid.net/signon/1.0"
[1]=>
string(32) "http://specs.openid.net/auth/2.0"
}
["args"]=>
object(Auth_OpenID_Mapping)#373 (2) {
["keys"]=>
array(11) {
[0]=>
array(2) {
[0]=>
string(14) "Bare namespace"
[1]=>
string(13) "janrain_nonce"
}
[1]=>
array(2) {
[0]=>
string(14) "Bare namespace"
[1]=>
string(18) "openid1_claimed_id"
}
[2]=>
array(2) {
[0]=>
string(32) "http://specs.openid.net/auth/2.0"
[1]=>
string(4) "mode"
}
[3]=>
array(2) {
[0]=>
string(32) "http://specs.openid.net/auth/2.0"
[1]=>
string(11) "op_endpoint"
}
[4]=>
array(2) {
[0]=>
string(32) "http://specs.openid.net/auth/2.0"
[1]=>
string(8) "identity"
}
[5]=>
array(2) {
[0]=>
string(32) "http://specs.openid.net/auth/2.0"
[1]=>
string(10) "claimed_id"
}
[6]=>
array(2) {
[0]=>
string(32) "http://specs.openid.net/auth/2.0"
[1]=>
string(9) "return_to"
}
[7]=>
array(2) {
[0]=>
string(32) "http://specs.openid.net/auth/2.0"
[1]=>
string(14) "response_nonce"
}
[8]=>
array(2) {
[0]=>
string(32) "http://specs.openid.net/auth/2.0"
[1]=>
string(12) "assoc_handle"
}
[9]=>
array(2) {
[0]=>
string(32) "http://specs.openid.net/auth/2.0"
[1]=>
string(6) "signed"
}
[10]=>
array(2) {
[0]=>
string(32) "http://specs.openid.net/auth/2.0"
[1]=>
string(3) "sig"
}
}
["values"]=>
array(11) {
[0]=>
string(26) "2008-08-27T19:34:04ZdhoC3H"
[1]=>
string(28) "http://localhost:7064/user/1"
[2]=>
string(6) "id_res"
[3]=>
string(37) "http://localhost:7064/openid/provider"
[4]=>
string(28) "http://localhost:7064/user/1"
[5]=>
string(28) "http://localhost:7064/user/1"
[6]=>
string(164) "http://localhost:9009/login/index.php?janrain_nonce=2008-08-27T19%3A34%3A04ZdhoC3H&openid1_claimed_id=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0%2Fidentifier_select"
[7]=>
string(24) "2008-08-27T19:34:04ZNUZB"
[8]=>
string(0) ""
[9]=>
string(69) "op_endpoint,return_to,response_nonce,assoc_handle,identity,claimed_id"
[10]=>
string(28) "DAMRSk0amkW2/hfO3Qt7ig42/rg="
}
}
["namespaces"]=>
object(Auth_OpenID_NamespaceMap)#372 (2) {
["alias_to_namespace"]=>
object(Auth_OpenID_Mapping)#371 (2) {
["keys"]=>
array(1) {
[0]=>
string(14) "Null namespace"
}
["values"]=>
array(1) {
[0]=>
string(32) "http://specs.openid.net/auth/2.0"
}
}
["namespace_to_alias"]=>
object(Auth_OpenID_Mapping)#370 (2) {
["keys"]=>
array(1) {
[0]=>
string(32) "http://specs.openid.net/auth/2.0"
}
["values"]=>
array(1) {
[0]=>
string(14) "Null namespace"
}
}
}
["_openid_ns_uri"]=>
string(32) "http://specs.openid.net/auth/2.0"
}Plenty of namespaces there, but none named exactly as expected. Not sure if it's a bug at all (since I'm not conversant in the OpenID protocol), or if it is a bug, if it's yours or Moodles. Perhaps you can quickly determine which of the 3 it is. I can do some further debugging with a little direction as to what to pursue. Thanks.
#1
Bah. I should have debugged this further before writing. Moodle fails authentication as a consumer against Drupal's OpenID provider service, but not because of this namespacing situation. Moodle actually defaults to some sane value for the non-SSO option, but still fails to validate with a "bad signature" error. So there's something else wrong here.
Sorry for the premature issue. I'd just delete it but I can't. :-)