I want to implement an OpenID login system with latest LightOpenID release. I'm testing the example provided with the source code line by line (I just replaced localhost
with $_SERVER['HTTP_HOST']
in the constructor).
The issue is that everything works fine in my development box inside a private network (PHP/5.3.6 on Windows Vista) but validation always fails in my life server at the HSP public network (PHP/5.3.3 on CentOS).
I've added var_dump()
's all around and I can tell you that both copies of the code produce exactly the same request parameters and receive exactly the same response parameters (via GET). Only openid.assoc_handle
, openid.sig
, openid.response_nonce
and openid.return_to
have different values, which I guess is the expected behaviour.
However, my dev box receives this from the OpenID provider (no matter which one I use):
is_valid:true
ns:http://specs.openid.net/auth/2.0
... and my live fox receives this:
is_valid:false
ns:http://specs.openid.net/auth/2.0
There aren't any non-ASCII characters involved so it can't be an encoding issue. There must be something wrong in my hosting service but I just can't figure out what.
I need suggestions about possible causes and troubleshooting tips.
I've isolated the problem and found a workaround. The
request()
method makes some auto-detection to find out how to stablish HTTP connections:In my dev box is uses CURL but in my live box it uses
file_get_contents()
because the check fails. The reason is that theopen_basedir
directive is not empty.If I force LightOpenID to use CURL, everything runs smoothly.
Update #1: LightOpenID was right when deciding that curl was not usable. I found this in the log file:
As for the
file_get_contents()
version, I suspect I've found a typo in the library:I've notified the author and he's confirmed it's a bug. I'll report back if it gets fixed.
Update #2: The bug was fixed in master branch on June 2012. It's still not part of the stable release but can be downloaded from the code repository.