mod_auth_openid occasionally fails with error=invalid_nonce

[foresto]

mod_auth_openid sometimes fails on a perfectly legitimate authentication, passing to my custom login page the error code "invalid_nonce". I have enabled debugging, but the logs don't say anything about the error.

I'm using a mod_auth_openid snapshot from 2010-11-08. The same problem occurred in version 0.5.

(Could this be related to issue #4?)

[bmuller]

Can you compile with --enable-debug and set the apache log level to debug and then paste the output of your error log here?

[foresto]

I already had an --enable-debug build installed and LogLevel set to debug. This is the only message from mod_auth_openid when the problem occurred:

[Sun Nov 28 09:02:59 2010] [debug] mod_auth_openid.cpp(426): [client x.x.x.x] *** mod_auth_openid 0.6 module has been called ***

[mokaspar]

I think, that part of the problem is to be found in the function get_request_params(...):
It either reads the GET or the POST arguments. Some libraries (for example the janrain php-provider library) writes the nonce-parameter into the GET-string and all the other into the POST-data, if the payload is too long.
I think, the problem might be solved, by combining the params from both, the POST and the GET-sources, if available.

[foresto]

It seems like sound reasoning, and I am aware that the openid spec wants HTTP POST for large assertions, but I'm not sure why a single openid provider with relatively short IDs and no extra attributes would only occasionally switch to POST. The python janrain library has a 2kb threshold before switching, and I don't think I've ever seen our server's assertions grow to anywhere near that size. Also, our server doesn't use javascript to automate a POST, so the user would be presented with a very noticeable "Continue" form if this was happening.

In any case, I'm sorry to say that I would have a hard time testing your theory, since I have decommissioned mod_auth_openid on my servers. (Too many failures make bosses unhappy.)

[mokaspar]

it might be connected to the bug described in issue #10. '+' and '%20' is used to escape a space. if you use AX, you run into trouble, since libcurl only unescapes the %20 correctly. the janrain-library uses the +. => the validation fails.

[foresto]

Good to know, but I don't use AX, and I don't know why this would cause a problem only occasionally instead of every time.