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

Have you written a response to this? Let me know the URL:

I tried HEAD from trunk and it's a little slow in working (After having authenticated with OpenID), but it definitely works, great job Will.
hey, do you plan on giving the option of connecting an wordpress account that already existed before with an openID account? please let me know, i'd love to hear more about this feature. thx.
@philsblogging: uhm, that's already possible. Once you're logged in, go to your profile page and click on "Your Identity URLs".

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?

it works only for comments, if i try to register my uri to my blog, page comme back to the submit form. :(

i think wp-openID have some bugs that will conflict with other plugins. for example, wp thread comment. will you fix it?

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.

I am afraid that I have to report an error. If I try to combine my already existing account it takes me to clickpass.com and then straight back to the user overview, but nothing happened? My OpenID provider is Clickpass.
Hey, when people post words with apostrophes like “I’m thinking, don’t do it!”, it escapes the apostrophes in the end result and looks weird, like the above will become “I'm thinking, don't do it!”. Can this be caused by your plugin? Because it only happens with people who post comments from OpenID. Using HEAD from svn.
Revision 315 is broken for me. Many users have told me that it no longer authenticates them with OpenID and redirects them to my blog’s front page with a very long URL. Please try for yourself by commenting here: http://www.blaenkdenum.com/new-star-wars-clone-wars-trailer . I’m not sure if this is a work in progress bug or something, being that it’s the latest revision, but I don’t remember the revision I was using before that so I can’t revert to a working version. Thanks for any help you can give!

@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
What was that last bit? I’m not OpenID Savvy, The only OpenID related things I have are WP-Yadis and your OpenID plugin.
I did what you said and I’m hoping that it works from now on. It probably had to do with the fact that the new revision is called 0_WP-OpenID and the older version was something else.

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.

Alright I'll use that then. I'm using that right now for this comment so I hope it works. Sorry for the ignorance, I thought my comments would help out with development, I had no idea that they were just full of ignorance. My blog though isn't all that popular and I'm constantly working on it so using something experimental on it is no problem I can assure you. My only remark was that I wanted to know the previous version that worked, but now it seems like you have solved my problem (I thought that HEAD didn't work because of Work in Progress).
The XRDS-Simple plugin obviously worked, but your plugin still doesn't. I rebuilt the permalink structure, rebuilt the plugin's tables, and finally cleared my super cache and still nothing. I wonder if it has anything to do with the fact that I'm testing it with my openid, blaenkdenum.myopenid.com and the fact that that site is also its delegate, though I didn't have this problem before. Logging in doesn't work either. With logging in I get <a href=\
Well, that didn't go well. Simply put I said that I will wait until you finish the plugin to not get 'in the way' of things. I never should've updated from that other revision I was using which worked (Whichever revision that was).
Score! :D I did the obvious thing (How could I have overlooked it earlier) and checked the date of the comment I posted saying 'it worked' above and looked in the svn log for the last revision at or before that date. I'm at revision 228 and everything is working perfectly fine. The reason I wanted to try it was because you said you needed testers and figured I should help testing given that I develop the recaptcha plugin which was one of the ones which had problems with this plugin, and the reason this plugin needs testing is because you're trying an alternative method of authentication which allows for the usage of these plugins (Like recaptcha). But hey I'll back off to avoid annoying you any further and wait for the stable release.

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.