Just a quick note: My authentication patch was accepted and should show up in WordPress 1.5.1, whenever that happens. I added the corresponding plugin to the WordPress plugin repository.
Update (2006-01-12): Version 1.4 released, which is updated to work with WordPress 2.0. It also provides better error messages if it can’t authenticate the user. You can download a zip from Owen Winkler’s site.
If you’re still using WordPress 2.0, please use version 1.8 of the plugin.
Update (2008-04-16): Changes in WordPress 2.5 are causing problems with this plugin. I’ve released an updated plugin that is compatible with the upcoming WordPress 2.5.1.
[...] uiring extra modules to be compiled and loaded. So I had a quick look at Daniel’s http authentication plugin, and coded up a imap authentication plugin. D [...]
This plugins is really cool. I use it together with registered_only to fully protect wordpress. There is unfortunately one very small snag. The registered_only plugin uses redirect-to=/ in the request to redirect back to the blog homepage.
This works normally because the variable is transferred from the _REQUEST array to the _POST array in the login page.
When using http_authentication, the login page is skipped, and wp-login does not see the redirect-to variable, so it will redirect the user to the admin section.
I hacked wp-login, but this is not very satisfactory. Do you have a clean solution?
–
Joost
Joost,
Please try the latest trunk version of http-authentication from http://dev.wp-plugins.org/. I added a workaround which sets the redirect_to parameter once WordPress has verified the login.
I tested it against WordPress 1.5.1.2 and the current trunk of Carthik’s registered-only plugin.
Works great, Daniel! I also like the fact that you dropped the user level required to configure it to 9. Thanks!
I’m trying to set this up with WordPress 1.5.2, fresh install, nothing out of the ordinary and as soon as I enable the plugin, I get lines like this everywhere:
Warning: Cannot modify header information - headers already sent by (output started at /usr/local/var/www/internal/news/wp-content/plugins/imap-authentication.php:153) in /usr/local/var/www/internal/news/wp-admin/admin.php on line 10
Warning: Cannot modify header information - headers already sent by (output started at /usr/local/var/www/internal/news/wp-content/plugins/imap-authentication.php:153) in /usr/local/var/www/internal/news/wp-admin/admin.php on line 11
Warning: Cannot modify header information - headers already sent by (output started at /usr/local/var/www/internal/news/wp-content/plugins/imap-authentication.php:153) in /usr/local/var/www/internal/news/wp-admin/admin.php on line 12
Warning: Cannot modify header information - headers already sent by (output started at /usr/local/var/www/internal/news/wp-content/plugins/imap-authentication.php:153) in /usr/local/var/www/internal/news/wp-admin/admin.php on line 13
Any Ideas? I have the same problem with the imap authentication module.
James,
Could you please provide the errors you get with the http-authentication plugin? The line numbers are different between the two plugins, and that will help me debug the problem.
Also, could you provide a list of all the plugins you have enabled? Thanks.
James-
The error regarding the headers already being sent could be because of a blank line either at the beginning or end of the file. I had this problem because I had copied and pasted the code to a new file and inadvertantly added a blank line at the top. PHP outputs this since it’s before the “
Is there any reason the code couldn’t be hacked to use a PKI client certificate information? mod_ssl provides $SSL_CLIENT_S_DN_CN (the user’s name); that could be passed to WordPress instead of $REMOTE_USER.
Thoughts?
Tom,
I’m not very familiar with the mod_ssl environment, but in theory that would work. Take a look at the authenticate function and let me know if it works out.
That sort of thing could probably be made into a plugin option - patches are welcome if you’re interested, since I can’t easily test it.
[...] So I had a quick look at Daniel’s http authentication plugin, and coded up a imap authentication plugin. [...]
Just a quick follow-up to the mod_ssl thoughts. I played with it for a bit, but ended up pursuing Kerberos authentication for other (corporate) reasons.
What I did find suggests this is pretty easy — but there’s a quirk in the WP user registration. The database allows 50 or 60 character login names, but wp-register.php only allows 20 characters of input (line 166). I had to expand that to make the Kerberos work (the authentication returns the username plus realm name, which is longer than 20 characters). Once I did that and killed all +FakeBasicAuth references things worked great.
There’s also a mod_ssl option to set the HTTP username environment variable to an arbitrary mod_ssl envrionment variable (like client DN). This should let me do most things in .htaccess without mucking wth the WP files. I’ll have to play with it later.
I got this installed a couple of days ago. I noticed that when I logout I could get back into WordPress without having to auth again (even though I redirected to me external logout mechanism). I did some looking, and it seems like this plugin isn’t clearing the WordPress cookies. So I added the following to the logout function:
wp_clearcookie();
nocache_headers();
That seemed to help. Is this just me, or should this get added to the general release of the plugin?
Kyle,
That’s interesting. The plugin’s
logoutfunction hooks into thewp_logoutaction, andwp_clearcookiefunction is called right before that.I wonder if you’re bypassing this - perhaps using a different URL than e.g.
http://dev.webadmin.ufl.edu/~dwc/wp-login.php?action=logoutto logout of WordPress? My 1.5.x and trunk installs all seem to clear the cookie.Are you going to code one for Wordpress 2.0?
Bob,
As noted WordPress 2.0 has been supported since version 1.4. I just tagged version 1.6 for improved compatibility. Let me know if you run across any problems.
[...] then I used http-authentication from http://dev.webadmin.ufl.edu/~dwc/2005/03/10/http-authentication-plugin/ to set up wordpress authentication, and finally added the following lines to my [...]
[...] Daniel Westermann-Clark’s HTTP Authentication WordPress Plugin, which automatically logs people in if the REMOTE_USER environment variable is set and creates the user if they don’t exist, [...]
I have been having problems (same with James Cole) with HTTP Authentication Plugins. it’s a good thing I came across this post. Maybe I’ll try John F Hall’s suggestion and will report back if it works. Thanks all.
Joe Orchid
[...] Visit [...]
Does this work with WP 2.2?
thanks
Mike,
I’ve tested the plugin with 2.2 and 2.3. Are you running into problems?
Im have error to!
Warning: Cannot modify header information - headers already sent by (output started at /usr/local/var/www/emule/news/wp-content/plugins/imap-authentication.php:153) in /usr/local/var/www/internal/news/wp-admin/admin.php on line 10
Warning: Cannot modify header information - headers already sent by (output started at /usr/local/var/www/emule/news/wp-content/plugins/imap-authentication.php:153) in /usr/local/var/www/internal/news/wp-admin/admin.php on line 11
Warning: Cannot modify header information - headers already sent by (output started at /usr/local/var/www/emule/news/wp-content/plugins/imap-authentication.php:153) in /usr/local/var/www/internal/news/wp-admin/admin.php on line 12
Warning: Cannot modify header information - headers already sent by (output started at /usr/local/var/www/emule/news/wp-content/plugins/imap-authentication.php:153) in /usr/local/var/www/internal/news/wp-admin/admin.php on line 13
Any Ideas? I have the same problem with the imap authentication module.
It work in 2.0?
I installed the HTTP Authentication plugin, and now posting from a desktop client is giving me trouble. In short, xmlrpc.php doesn’t go through the same code path as the rest of WP for verifying usernames and passwords, so my blog client has to first perform HTTP auth (in order to access xmlrpc.php in the first place) and then post my *WP* username and a password to xmlrpc.php. This is inconvenient, because I now have to store two passwords to access my blog in my desktop client; also, it’s hard to reset my WP password once HTTP Auth is installed.
My guess is that user_pass_ok in user.php needs to be patched to talk to WP plugins.
Ben,
I’ve had one other report of this problem. Unfortunately I’m not familiar with XML-RPC, so you could really help out by patching WordPress and the http-authentication plugin.
Is this working for anyone in WP 2.5? I’m having trouble, and trying to isolate the issue.
It seems like HTTP Auth is happening but then I’m being dumped on the wp-login.php instead of wp_authenticate doing its thing. Anyone else?
Same problem as Ben.
Yep. Experiencing the same thing. Can’t upgrade to 2.5 unless I can get this working, because I have dozens of WP accounts that rely on this plugin.
[...] noted elsewhere on this blog, the http-authentication plugin does not run smoothly on WordPress [...]
[...] http-authentication plugin required for the fancy Pubcookie authentication instructions for WordPress does not function with [...]
[...] for this release, I’m starting a new post for the plugin. Refer to the previous post for support issues, and if you don’t find an answer there, please ask here. Questions asked [...]
Same problem as ben - having a hard time getting it to work.