This allows plugins to add their own functions into the filter chain which populate the WP_User object Wp-login.php and does the normal checking for the WordPress authentication cookie.īoth of these functions first check to see if the first parameter passed in is a valid WP_User object, and immediately Wp_authenticate_cookie() (priority 30) is only added into the filter chain when the user is authenticating via This function also performs the check for an empty username or password. It still calls the wp_authenticate_user filter, so plugins that rely on that should be fine. Wp_authenticate_username_password() (priority 20) includes the standard logic for authenticating using a standard All of the standard WordPress authentication logic has been moved into two functions that implement thisįilter, both with relatively low priority. WordPress 2.8 includes a new filter called authenticate which is passed three parameters: a mixed value (eitherĪ WP_User object, a WP_Error object, or null), along with the username and password (either or both of which mayīe null). Username and password, but maintains backward compatibility with existing plugins that hook into the authenticationĬode. It took far more planning than actual coding, but we finally developed a solution that breaks the dependence on a Instead, Peter Westwood came up with a better solution using a well-established model, which we ended up using for One possible solution is to create wrapper functions for everything, which I initially advocated. This is actually the case for all functions in The function call back to the standard version of wp_authenticate(). Replaced, and then the plugin determines it shouldn’t intervene, then it’s already too late. The problem with this solution is that manyĪuthentication mechanisms don’t know if they should be invoked without examining the request. Heavy lifting for WordPress authentication, resides in pluggable.php it is possible for a plugin to replace theįunction entirely and authenticate the user however they want. Because the wp_authenticate() function, which does most of the It’s worth noting one additional requirement we had. It came to hooking OAuth into the WordPress XML-RPC endpoint, there simply was no way to hack around it… we had toĬhange some of the underlying assumptions. Interesting things that need to be done in order to make it work on the various versions of WordPress. You can look at the OpenID plugin to see some of the more That do not fit the standard model of username and password. The problem is that there are a number of authentication systems widely deployed in the wild (SAML, OpenID, OAuth, etc) This isn’t a problem if your plugin simply wants to authenticate the user against aĭifferent password store like LDAP in fact that works quite well. There are places in the authentication code where it bails out prematurely if the It wasn’t very long before we butted up against my biggest complaint about the WordPress authentication system – it is IPhone app to communicate with your blog without having to share your WordPress password. Having OAuth authentication with XML-RPC would allow for blog clients like MarsEdit or the WordPress The first use-case we wanted to tackled was XML-RPC, so I got to work with We’ve had an OAuth plugin for a little while that Stephen Paul Weber wrote, but it wasn’t until a couple of monthsĪgo that I finally sat down to polish it up. Of smoke and mirrors at that point… we didn’t have OAuth in WordPress, although it was on the roadmap for 2.7. As you can see in my slidedeck, it was a lot Matt Mullenweg invited me to talk at WordCamp SF 2008 about OAuth. WordPress two years ago, and was hired by Vidoop last May to work on the DiSo Project full time. I’ve spent a lot of time working with the WordPress authentication system.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |