2718.us blog » user login http://2718.us/blog Miscellaneous Technological Geekery Tue, 18 May 2010 02:42:55 +0000 en hourly 1 http://wordpress.org/?v=3.0.4 Authenticating with WordPress 2.6 (part 3) http://2718.us/blog/2008/08/03/authenticating-with-wordpress-26-part-3/ http://2718.us/blog/2008/08/03/authenticating-with-wordpress-26-part-3/#comments Sun, 03 Aug 2008 23:55:48 +0000 2718.us http://2718.us/blog/?p=82 So, as a followup to parts 1 and 2, per WordPress Trac ticket #7001, WordPress 2.6 has split up the login cookies into three parts:

  • what was the one and only login cookie in 2.5 is now limited to /wp-admin
  • there’s a copy of that one that’s just limited to /wp-content/plugins, for backward compatibility with plugins
  • there’s a new cookie that is at COOKIEPATH (which can be defined in your config file), that is checked by calling
    is_user_logged_in()

    (but perhaps this isn’t intended for secure authorization?)

So, it appears the way to go may be to change

auth_redirect()

to

  1. if (!is_user_logged_in()) auth_redirect();

Maybe more to follow on this when I’ve more thoroughly explored it.

]]>
http://2718.us/blog/2008/08/03/authenticating-with-wordpress-26-part-3/feed/ 8
Authenticating with WordPress 2.6 (part 2) http://2718.us/blog/2008/07/29/authenticating-with-wordpress-26-part-2/ http://2718.us/blog/2008/07/29/authenticating-with-wordpress-26-part-2/#comments Wed, 30 Jul 2008 04:32:54 +0000 2718.us http://2718.us/blog/?p=70 Having stated the problem and now played further, I’ve got good news and bad news.

The good news is that there’s an action hook, ‘set_auth_cookie’, that gets called whenever the cookies are set, so if the stuff for which you want to authenticate is on the same server but at a different path, you can create a plugin (or maybe use functions.php in your theme?) with something like the following:

  1. function your_unique_name_here_set_auth_cookie($auth_cookie, $expire, $expiration, $user_id, $scheme) {
  2.     setcookie(AUTH_COOKIE, $auth_cookie, $expire, '/path/to/your/stuff', COOKIE_DOMAIN);
  3. }
  4.  
  5. add_action('set_auth_cookie','your_unique_name_here_set_auth_cookie',10,5);

The bad news is that if your WordPress install is at example.com/something and you want to use it to authenticate at portal.example.com, you can’t set a cookie for portal.example.com from a script on example.com, so your only choice would be to set a cookie with path / on .example.com (note the leading period), which completely breaks the security added by the separate cookies.

Hopefully, there’ll be a “part 3″ to this wherein I solve this last problem somehow, since that’s the setup I’m dealing with.

]]>
http://2718.us/blog/2008/07/29/authenticating-with-wordpress-26-part-2/feed/ 1
Authenticating with WordPress 2.6 (part 1) http://2718.us/blog/2008/07/29/authenticating-with-wordpress-26-part-1/ http://2718.us/blog/2008/07/29/authenticating-with-wordpress-26-part-1/#comments Wed, 30 Jul 2008 03:03:51 +0000 2718.us http://2718.us/blog/?p=68 I’ve been hoping for the last hour or two that there’d be just one post on this topic, giving the problem and solution all together, but I have yet to solve it and so I’m just going to post the issue for now, until I have a solution.

As a security measure in WP2.6, login cookies are now split into what seem to be at least three different cookies—two with paths like /wp-admin and /wp-content/plugins that are the full cookie that auth_redirect() checks against and one that’s different, with path / [paths relative to the blog root].  Near as I can tell, this immediately breaks any attempt to use auth_redirect() for authentication (e.g. this and this) outside the /wp-admin and /wp-content/plugins directories.  It is also not immediately clear to me how to authenticate against the whole-site cookie, if there’s any way to do that at all.

A temporary, but very bad fix would be to completely defeat the security by defining ADMIN_COOKIE_PATH to be the site root, rather than the path to /wp-admin.  I’m thinking that, from a quick skim of pluggable.php, there might be plugin action hooks to allow setting other cookies that would allow authentication on other paths…

]]>
http://2718.us/blog/2008/07/29/authenticating-with-wordpress-26-part-1/feed/ 2
Using WordPress for User Authentication, Part 2 http://2718.us/blog/2008/04/16/using-wordpress-for-user-authentication-part-2/ http://2718.us/blog/2008/04/16/using-wordpress-for-user-authentication-part-2/#comments Wed, 16 Apr 2008 18:08:33 +0000 2718.us http://2718.us/blog/?p=22 After implementing other pages that used WordPress to authenticate users and deal with access control, I went to move these pages off to a subdomain, and suddenly found that auth_redirect wasn’t quite working right.  When auth_redirect is called and doesn’t find a logged-in user, it redirects to login and passes the URI of the current page… well sort of.  It passes the request string, but it ignores the server part.  So, when the login page is done and tries to redirect, it’s going back to the main WordPress server, not the subdomain.  Fortunately, auth_redirect is a very simple function to duplicate and it is designated as pluggable–that is, a plugin can be used to redefine auth_redirect, so I’ve now got a plugin that overrides auth_redirect() with auth_redirect($use_current_host = FALSE) so that if I want auth_redirect to pay attention to the host, I call auth_redirect(TRUE).

This is all fine and good, but still doesn’t quite work, since WordPress is smart and won’t just redirect anywhere willy-nilly.  It will only redirect to authorized-for-redirecting servers (wp_safe_redirect, which doesn’t have any documentation in the Codex).  Though undocumented (or at least not well documented in the Codex), the way the authorized host list is handled allows for a plugin to add a filter hook that modifies the allowed list (since the allowed list by default only includes the actual WordPress server name and isn’t exposed as an option/setting anywhere).  Toss that hook into my plugin, add on a settings page to allow the admin to input a comma-separated list of allowed-for-redirecting hosts, and now I can use WordPress to authenticate users on subdomains.

If anyone is interested in this plugin, please let me know and I’ll try to clean it up engouh to make it public.

]]>
http://2718.us/blog/2008/04/16/using-wordpress-for-user-authentication-part-2/feed/ 2
Using WordPress for User Authentication http://2718.us/blog/2008/04/12/using-wordpress-for-user-authentication/ http://2718.us/blog/2008/04/12/using-wordpress-for-user-authentication/#comments Sun, 13 Apr 2008 04:56:37 +0000 2718.us http://2718.us/blog/?p=15 Plenty of people seem to have written a lot about how to make WordPress use some other program’s user authentication mechanism, but there seems to be fairly little on how to get at WordPress’s user authentication from some other program.  Fortunately, I found this article, and got what I wanted.

It’s a fairly straight-forward process.  At its simplest:

require_once('wp-config.php');
  1. auth_redirect();

Including wp-config.php (you may have to watch the path) gets you just about all of WordPress and auth_redirect() will check if the user is logged in to WordPress and if not, they get bounced to a login form.

Where things get trickier is if you want to use the authentication on a subdomain (you have to tweak COOKIE_DOMAIN in wp-config.php [to override what’s already in wp-settings.php) or if your blog is in a subdirectory and you want the authentication outside that subdirectory (try tweaking COOKIEPATH).

Oh, and if you try to put the require_once() statement inside a function, you will also need

global $wpdb;

or nothing will work.

The issue of how much memory it consumes to load all of WordPress just to authenticate users is a whole separate issue.

]]>
http://2718.us/blog/2008/04/12/using-wordpress-for-user-authentication/feed/ 4