PURL querystring appending breaks OpenID trust_root and causes OpenID login to fail

PURL uses querystrings for rewriting, as in the case of views-modes for Managing News. It changes localhost/feeds/ to localhost/feeds/?display=view-mode-list in most links. However, we have a nice user login block that allows OpenId logins. openid.module on line 499 has a function called openid_authentication_request(). It sets

  if ($version == 2) {
    $request['openid.realm'] = url('', array('absolute' => TRUE));
  }
  else {
    $request['openid.trust_root'] = url('', array('absolute' => TRUE));
  }

And PURL, predictably, changes this to localhost/?display=views-mode-list. This is bad, because that doesn't fly as a base root for the myopenid.com standard; it says:

The request was not a valid OpenID request. While processing the request, the following error occurred: return_to u'http://localhost/mnbeta11/openid/authenticate?destination=feeds%3Fdispla...' not under trust_root u'http://localhost/mnbeta11/?display=views-mode-list'

I'm not sure exactly what it does to determine this (maybe it just wants the return-to to begin with the trust_root in a simple string comparison), which might be important... Anyway, this should be fixed. A quick workaround that probably has repercussions in cases where PURL needs to rewrite this base URL, as for languages and so forth that are appended to the beginning of the request, is adding this hook to the end of purl.module:

function purl_openid($action, $request) {
  if ($action == 'request') {
    if($request['openid.realm']) {
      $request['openid.realm'] = url('', array('absolute' => TRUE, 'purl' => array('disabled' => TRUE)));
    } else if ($request['openid.trust_root']) {
      $request['openid.trust_root'] = url('', array('absolute' => TRUE, 'purl' => array('disabled' => TRUE)));
    }
    return $request;
  }
}

I'm not all that familiar with the PURL API--certain rewriters can be disabled it seems, so perhaps we should do this hook specific to MN and our hook. Or maybe only suffixes and not prefixes can be disabled somehow? Anyway, requires more testing and thought.