PHP Consumer and misc things

[Dan Libby]

Hi Zefiro,

First, a general statement.  The PHP code is a direct port of the Python
code, which I did not write.  I intend to keep it as functionally and
API compatible as I can.   So the python folks are presently better
qualified to answer "why does it work this way" types of questions. Or
to put it another way, if there is a problem in one library, there is a
good chance the problem exists in both.  And I'm a bit averse to fixing
things in the PHP version without getting the same fix back into python
upstream, so it requires some coordination.

Zefiro wrote:

>Hi, List, especially Dan
>
>I'm now using your PHP Consumer library (0.0.8.3) for my diary - http://diary.zefiro.de - and it seems to work fine (PHP 4.4.0).
>Thanks for your work.
>  
>
Your welcome.  Glad it is working for you.  My thanks go to Janrain Inc
also for the python lib.

>(I could give you my login.php with sessions to put into the example directory - though I assume you already have done something
>similar within the MediaWiki-Patch)
>  
>
If you'd like to send it to me, I can evaluate for inclusion.  Sessions
are probably better than the file-based example presently included,
which would break under concurrent access situations given there is no
file locking.

>Just a few things, though, I mentioned while implementing it:
>- in your simple.php example you don't use the form input parameter field name 'openid_url' as is recommended in the spec (step
>2). You also don't do this for your Mediawiki-Patch. (btw, adding the OpenID-Icon there would be nice, too)
>  
>
Thanks for pointing this out.  The simple.php example does not do it
because the python version doesn't.  There should be a cleaner interface
and some better examples in the next major release.  Carl, care to
elaborate here?

The MediaWiki patch does not use it because it piggy-backs on the
existing login form and input field.  I tried to make the patch as
un-obtrusive as possible so as to avoid breaking things I don't
understand.  Probably MediaWiki will ultimately have some sort of
selector widget in the form to choose what login type the user desires,
but I'm not the right person to build such a thing.   I'm open to
patches to my patch though.    :)

>- the example httpconsumer.php didn't work for me. When called on the local host 172.20.x.x and entered 'zefiro.de' it forwards
>me to livejournal.com, but only gets a blank page. Perhaps this is a bug in the lj-code, not accepting 'private' ip ranges?
>(localhost works fine, though). Entering the url of the also local sampleserver.php gave me multiple errors ('Association server
>response missing argument assoc_type')
>  
>
I'm not sure about this.  Does the login work with other OpenID
servers?   If so, probably an LJ issue. 

Strange that sampleserver gives you a problem though.  Does it work
correctly for localhost?  If not, it must be some config issue.

You could also try assigning a hostname to localhost via your hosts
file.  But that shouldn't be necessary.

>Generally the lj-OID-serverpage seems to be quite picky - if something is not ok it just returns an empty page instead of some
>kind of error message. I had this e.g. with errors in the trusted root. It is ok if you don't want to give attackers valuable
>debug information, but at least a 'the request was malformed. Please inform the webmaster of $return_url' would be nice.
>  
>
Agreed.  Also, some sort of interop test suite would be nice.  I'm not
sure exactly how it should be implemented though.  I remember that in
the early days of xml-rpc, userland put together a validator that helped
implementors achieve at least a minimum compliance level quickly.

>- the nounce is meant to be a one-time-token, as I understand it. It is generated in createReturnUrl, stored locally and checked
>in verify_return_url. (I use md5(microtime().date("r").rand(10000, 32000)) - found somewhere in the PHP doc/usercomments, as
>nounce and store it in the $_SESSION). But verify_return_url is called twice. Is this on purpose? If I'd delete the nounce after
>first use it would fail the second time, making login impossible.
>  
>
I don't have an immediate answer, and would have to dig into it a bit. 
Are you using dumb mode or smart mode?

>By the way, regarding the thoughts about how to display OpenID logged in user. I thought it best to have a separate 'Display
>Name', which the user can choose freely (perhaps uniquely for the scope of my site), which is initially filled with their
>claimed identity ('Zefiro.de' in my case). A link with both href= and title= to their canonical identity (the one Dans lib now
>reports back) comprise the OpenID-Icon and the display name. (The display name is filtered through htmlentities() first, the
>canonical identity is not yet assumed to be problematic). What are your opinions of doing so? I would like to establish this as
>'best practices'.
>  
>
I think a separate display name is a good way of doing it.  That way, it
can be their OpenID url ( or a non-canonical version of it ) or it could
be a real name or nickname.  MediaWiki seems to work this way, although
they do an annoying uppercase of the first character of the user ID.

For Videntity.org, it stores canonical URL and then usually displays the
shortest possible address that can be uniquely canonicalized back.  Eg:

http://danda.videntity.org/   => danda  ( rule: no "." == assume
videntity.org )
http://dandaddl.livejournal.com/  => dandaddl.livejournal.com
https://dandaddl.livejournal.com/ =>  https://dandaddl.livejournal.com
http://www.livejournal.com/users/dandaddl/  =>
www.livejournal.com/users/dandaddl/

To my eye, the usernames are a lot prettier without the protocol and
slashes.

I dunno if that's best practice or not, but it seems to work well so far.