Download & Extend

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

Project:Persistent URL
Version:6.x-1.0-beta13
Component:Code
Category:bug report
Priority:major
Assigned:Unassigned
Status:needs work

Issue Summary

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

<?php
 
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%3Fdisplay%3Dviews-mode-list&display=views-mode-list' 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:

<?php
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.

nobody click here