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.
Comments 1
Please note that the which-host-to-redirect-to issue doesn’t appear to be a problem in WP2.6 (i.e., there’s no need to plug over auth_redirect(), since the WP2.6 version includes the correct hostname in its redirect), but adding a filter to allow your desired host is still necessary.
Trackbacks & Pingbacks 1
[...] 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 [...]