Changes to wp-openid
Today I committed a few pretty substantial changes to wp-openid, changing how the OpenID flow happens. Effectively,
I’ve created a new single endpoint which receives all OpenID responses, located at /openid_consumer
. Previously,
these response were sent to a number of different endpoints depending on whether you were simply logging in, leaving a
comment, or adding a new OpenID to your WordPress account. Consolidating on a single endpoint has allowed me to cleanup
the wp-openid code considerably.
Posting comments
OpenID is integrated into comment posting by intercepting a comment submission to see if it includes a valid OpenID. If
it does, the user is sent to their OpenID provider to authenticate, and upon their return the comment is submitted.
Previously, the wp-openid plugin itself performed the comment submission, basically by copying the logic found in
wp-comments-post.php
. This introduced a number of problems, especially when using any other plugins that modify the
comment submission process such as reCaptcha. Violating DRY is bad, but necessary at times. Breaking other
plugins is really bad and had to be fixed.
The current solution I’m using is to capture the comment submission POST, do the OpenID dance, and then replay the POST (modified if necessary). If the OpenID dance results in the commenter being authenticated as a valid WordPress user, then the comment POST is modified to look like they were logged in all along. If the OpenID dance results in user attributes (via attribute exchange, sreg, hcard, foaf, whatever), then those values override what was included in the original comment form. If OpenID authentication fails for whatever reason, the idea is to give the user the option to submit the post without OpenID. This part isn’t finish yet, but will be before the release. Currently, if OpenID authentication fails, then the comment is very likely lost unless you use other means to save the comment. And of course, if any other plugins include additional data in the original comment POST, it will be included in the replayed POST.
Still left to do
Because all of the OpenID responses are being sent to /openid_consumer
, it’s not quite as simple to display friendly
messages to the end user. I’m may try to find a way to display error messages similar to how they look today (for
example, login errors are displayed on the wp-login.php page, etc). Otherwise, I’ll just have a somewhat generic error
pages that is specific to OpenID errors, and then include links back to whatever the user was doing.
Need Testers
Right now, I’m in need of people to test this new version of the plugin to find any cases I may have overlooked. Like I
said, the message display is in need of work, but everything is at least functional as best as I can tell. If you’re
interested in testing, checkout a copy of the latest code from the Diso Repository and give it a shot. If you have
an older version installed, you will most certainly need to disable it first, then re-enable after installing the new
version. Otherwise, WordPress won’t handle the /openid_consumer
endpoint properly. If you have any questions or
comments, you can leave a comment here or on the Diso Mailing List. As always, I would strongly discourage you from
using this on your production WordPress installation (notice I’m not using it here).
Comments and responses
hello, wp-openid's author.
i think wp-openID have some bugs that will conflict with other plugins. for example, wp thread comment. will you fix it?
Hello,
plugin is not working with myid.net :(
[quote comment="21056"]
i think wp-openID have some bugs that will conflict with other plugins. for example, wp thread comment. will you fix it?
[/quote]This is currently fixed in the latest trunk code and will be included in the next minor version (2.2)
Can't wait for 2.2 :)
By the way, on this page we have to fill out the name and email even if we're using OpenID, is this normal? I thought I remembered being able to simply supply the OpenID URL.
@Blaenk: regarding your users being unable to authenticate… deactivate the plugin, go to your permalinks setting page and click “save changes” (you don’t actually need to change anything), then reactivate the plugin.
There is also something messed up with your own OpenID that is preventing discovery from succeeding… not sure exactly what, just yet.
Err, I remember what it was now. Your advertised XRDS document is only served up when “accept: application/xrds+xml” is included in the request. This should not be necessary. I think you’re mixing the following two discovery methods:
- a request with “accept: application/xrds+xml” to your OpenID itself should return your XRDS document
- a plain request to your advertised X-XRDS-Location should return your XRDS document without any special headers
no, the 0_WP-OpenID name has nothing to do with it. That is there because I got tired of scrolling down the page to deactivate and reactivate the plugin.
If you’re not OpenID savvy, you probably should not be running unreleased code. The plugin is in very active development and running out of trunk is dangerous. Please note the last line of this blog post: I would strongly discourage you from using this on your production WordPress installation
Regarding your other comment, get rid of wp-yadis and use this instead. That functionality will eventually be integrated into wp-openid.
Hi, Will, I’m actually only leaving this comment to see if I can get wp-openid on your blog to accept my myVidoop delegated login. It’s not working any more on my blog.
Thanks, and fee free to delete this comment!
Hi!
Thx for fixing the $_POST issue :) I developed Simple OpenID last year and also did the replay dance with code found in wp-comments-post.php :p It’s great to see you found a workaround for the $_GET block.
I tested revision 338 against the anti spam plugin WP Mollom. I did have issues with $_POST with version 2.1.9 of WP OpenID but the development version works like a charm.
Thanks for fixing this :)
With regards.