openid.module sends 'q' in check_authentication POST request

openid.module creates an authentication request by copying an authentication response (line 559), but that response (if created via a query string) contains a 'q' entry, for the local Drupal's path. It then sends this in a POST to the provider, even though AFAICT a 'q' field is not part of the openid spec. ;-)

This might not be a big deal, except that if the provider is also a Drupal installation, it then receives both a GET version of 'q', *and* a POST version... which in my situation leads to "access denied" on the provider, causing an authentication failure on the site where the login or openid linkup is taking place. Adding this:

unset($request['q']);

at line 561 of revision 1.19.2.11 of Drupal 6.20 fixed the issue for me.

In principle, the existing code can end up sticking other things in its outbound sends, perhaps leading to some sort of reflected attack vector, so maybe it should only put openid-specific fields in the outgoing request. But for me, this at least fixes the immediate problem of just not working when another Drupal is the openid provider. We *know* q is set, and we know it's not needed, so we also know we can delete it.

(Another possible fix, of course, would be to prevent it getting any non openid.* keys into the response in the first place... come to think of it, I have seen some query strings go by that had two 'destination' fields -- so it wouldn't surprise me if that's getting sent out somewhere too.)