What is the URL that is causing the 404?
It’s possible that your permalinks didn’t get updated… try going to the permalinks settings page, and click “Save Changes”. You don’t actually need to change anything, just resave.
I see the exact same thing.
My site url (“WordPress address (URL)” in General settings) is http://domain.com/wordpress.
My blog url (“Blog address (URL)” in General settings) is http://domain.com.
The OpenID permalink appears to be relative to the blog url while the consumer URL that gets sent to MyOpenID is relative to the site url. So, MyOpenID redirects me back to http://domain.com/wordpress/openid/consumer and I get a 404. If I edit the address in the Address Bar to http://domain.com/openid/consumer, everything works fine.
At the moment, I’m not sure how to fix that. I’m on WordPress 2.8.5 and OpenID 3.3.2.
The same error also started happening to me. I was able to make it stop by editing “openid/common.php”.
On line 619, where it says
$url .= 'index.php/openid/' . $service;
I changed it to
$url .= 'openid/' . $service;
And now I have no more problems.
I have the same problem (albeit with the server rather than the consumer) – it started (I think) with the upgrade to 2.8.4 with version 3.3.1, persisted with 2.8.5 and 3.3.1, and now remains with 2.8.5 and 3.3.2. I have uninstalled and reinstalled the plugin with no change in the behaviour.
bbqiguana’s suggestion doesn’t work for me, unfortunately. Like jmartin, if I edit the URL to remove the “wordpress/” bit, the 404 disappears, and I am returned to the site I was attempting to use openID from (blogspot in this case), which then reports an openID failure.
I have had the same problem recently. I haven’t tried bbqiguana’s suggestion of editing openid/common.php, but I’d like to avoid that.
I disabled my other plugins and changed to Kubrick to see if some other recent changes had caused this, but it still occurs.
For me, I get the OpenID confirmation page (“http://site has asked to verify your identity. Click Continue…” and the 404 page comes up after I click Continue.
wnorris, any other ideas?
Any news on this? It seems like the spurious “wordpress” in the URL is a fairly major clue as to what’s going on. I can’t see anything obviously wrong with the openid_service_url() function, though, and when I tried hard coding the return value…
`$url = ‘http://www.deadbadger.net/openid/’ . $service
…it did absolutely nothing. Authentication requests to my site still get directed to http://www.deadbadger.net/wordpress/openid/%5B…%5D. Is some other function generating URLs?
P.S. – a revert to 3.2.2 solved it.
I’m seeing a Forbidden error anytime I try to authenticate from another site:
Forbidden
You don’t have permission to access /blogs/dagan/ on this server.
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.
Apache/2.2.11 (Unix) mod_ssl/2.2.11 OpenSSL/0.9.8i DAV/2 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635 Server at epyllionco.com Port 80
I’m running MU 2.9.2 and OpenID 3.2.2. All other plugins are disabled, except XRDS-Simple.
I was having the same or a similar problem: logging into an external OpenID-enabled site with my root URL (where my blog is published) led to a 404 error on my own site.
I’m using WP 3.0.
I tried editing the URL to remove the “wp” (it was wp in my case, not wordpress) and that took me to the
This is an OpenID Server.
Nothing to see here… move along.
error, but didn’t log me into the external site.
Tried downgrading to 3.2.2 as suggested, and it then took me straight to the “Nothing to see here” error, without having to edit the URL, but that of course doesn’t solve the problem.
Still have this problem with WP 3.0.1 and OpenID 3.3.3. It is quite definitely not noticing that my WP installation is in the root directory, as it’s adding spurious “/wordpress” prefixes to its URLs that cause 404s. For example, if I use the Open-LDAP test page, I get directed to:
http://www.<mydomainname>/wordpress/index.php/openid/server
If I delete the “/wordpress” bit, I get to the authentication page, but obviously this doesn’t work for the next step, as there’s form data that gets lost when the URL is edited.
Devs, is this enough information to go on? A fix would be greatly appreciated, so if there’s anything else that I can provide, I’m happy to do so…
