首页 > 新闻资讯 > WordPress 2.8中的认证系统

WordPress 2.8中的认证系统

3条评论
标签:
更多

使用情况

我花了很多功夫研究WordPress的认证系统。 两年前我接手WordPress的OpenID插件开发工作,去年五月又被Vidoop聘请来全职研究DiSo项目。 去年夏天,我应Matt Mullenweg的邀请在 WordPress 2008年的San Francisco 夏令营中讲述关于OAuth的问题。 你可以在我的 slidedeck看到,那时这仅仅是一个幻象…当时WordPress中还没有OAuth,尽管在产品计划书上已经列出这一规划。

Stephen Paul Weber写到,我们刚开发出一款OAuth插件,但直到几个月前我才有时间改进这款插件。 我们要解决的第一个使用问题就是XML-RPC,因此我开始与Joseph Scott合作。 如果给博客客户端(如MarsEdit或WordPress iPhone app)添加Oauth认证程序,客户端就可以直接与你的博客交流而不必用到你的WordPress密码了。

出现的问题

不久前我们终于解决了我对WordPress认证系统的最大埋怨——太“用户名/密码”化了。 如果忘记用户名或密码,认证程序的代码中过早跳出空白。 如果你的插件只需要验证用户名是否与LDAP中存储的密码一致,这就很容易了;事实证明一切运行良好。

问题是,虽然外界开发了大批认证系统(如SAML,OpenID,OAuth等),但它们都不符合用户名和密码的标准模式。 你可以到OpenID插件上看看一些更有趣的东西,它们都需要人为完成以便在不同版本的WordPress上运行。 尽管如此,在将OAuth代码连接到WordPress XML-RPC终点时,我们没有办法绕过这一步骤…我们不得不改变一些基本的设想。

这个额外要求也没有什么作用。 因为wp_authenticate()函数驻留在pluggable.php中,该函数承担WordPress认证的大部分工作,这样插件就有可能完全取代函数的功能并随意对用户进行认证了。 这个方法带来的问题是,很多认证机构在不检查请求的情况下无法辨别它们是否被调用。 取代wp_authenticate函数之后插件才发现它本不应该如此,但这时已经太晚了。 我们无法避免在回到wp_authenticate标准版本时遇到这个函数。 事实上pluggable.php中所有的函数都是这样。一个可行的解决方案是为每个函数创建包装器函数,这也是我最初所主张的。 但Peter Westwood想到一个更好的方法,可以采用一个已建成的模式,最后我们在新认证系统中采纳了他的意见。

解决方案

对这个方案的规划比实际编码要麻烦的多,但最终我们还是成功了,开发出的方案脱离了对“用户名”和“密码”模式的依赖,同时还兼容连接认证程序代码的现有插件。 WordPress 2.8 含有一个名为authenticate的新过滤器,它传递了三个参数: 一个混合值(可能是WP_User对象,WP_Error对象,或者空值),以及用户名和密码(其值都可以为空)。 这样所有的标准WordPress认证逻辑就被移入下面这两个执行过滤器的函数了,它们的优先级相对较低。

  • wp_authenticate_username_password() (优先级为20)中包含用于标准“用户名”和“密码”验证的标准逻辑。 这仍被称为wp_authenticate_user过滤器,因此附着与该过滤器的插件仍然可以使用。 这个函数也执行对空用户名和密码的检查。
  • Wp_authenticate-cookie() (优先级为30)只在用户通过wp_login.php进行验证时才被加入过滤器链,它主要对WordPress验证cookie进行常规检查。

以上两个函数都会对第一个传递的参数进行检查,如果它是有效的WP_User对象则立即停止。 这就允许插件以适当形式将其自身函数添加到可生成WP_User对象的过滤器链中。 WordPress也在适当的时候设置了认证程序的cookie,因此插件只需要负责认证用户并返回有效的WP_User对象。

那么,对插件来说这意味着什么呢? 当然,WordPress的OAuth插件尚未完工,但下面的函数已经相当接近最终版本了。 实际执行OAuth仍然需要更多代码,这仅仅是能使WordPress认证程序连接生效的代码段。 请注意,认证程序钩子(hook)中的用户名和密码参数对本函数不产生影响…其他插件可能会用到这些参数。

add_filter('authenticate', 'oauth_authenticate');

/**
 * If the current request was signed using a valid OAuth access token, verify
 * the request and return the associated user.
 *
 * @param WP_User|WP_Error|null $user authenticated user
 * @return WP_User|WP_Error|null OAuth authenticated user, if request was signed
 */
function oauth_authenticate($user) {
    if (Auth_OAuth_Signer::requestIsSigned()) {
        $oauth_server = oauth_server();
        $user_id = $oauth_server->verify();
        if ($user_id !== false) {
            $user = new WP_User($user_id);
        }
    }  

    return $user;
}

写给插件开发者

如果你现在正要连接WordPress的认证系统,或者说你要为wp_authenticate()提供自定义工具,请先了解新认证程序的钩子(hook)。 如果你依赖于wp_authenticate hook,也请先了解新的hook是否能帮上你的忙。 我们现在已经把wp_authenticate hook安排妥当,但我坚信它已经不再是必需,也许新版本中我们就不再看到它了。 也许你只使用wp_authenticate_user hook,那么你可能是个高手,不过了解一下新事物也不是个坏主意。

在WordPress中使用会怎么样?

我们对WordPress XML-RPC代码又做了些附加更改,使它能够很好的适应新的认证程序,这样即使不做主要修改我们也可能将OAuth连接到WordPress。 事实上在WordPress的主版本中已经使用了基本的OAuth插件。但由于以下两个原因,我不打算将OAuth代码编入Wordpress 2.8中:

  • OAuth程序库目前正处于不断变化中。 人们常用两个PHP程序库来为OAuth服务,这两个程序库各有长短。 我用 oauth-php community将这些程序库中的精华部分合并,生成一个纯净的新结构。 在 github上可以看到这种效果。 (这个程序库要求PHP5运行环境,而PHP5将对WordPress产生不良影响…怎样处理这一情况还是个问题)
  • OAuth有可能成为与WordPress博客交互的第三方的重要部分,因此我希望我们的想法是正确的。 就个人而言,将代码先作为插件发布出去,并在相对受限的环境中得到一些实际经验,我会感觉轻松很多。 当我们完成以上事情,并对与WordPress(插件API,管理界面,数据库结构等)的连接感到满意时,我会举双手赞成OAuth成为WordPress的重要部分。

原文:Authentication in WordPress 2.8

* 版权声明:作者WordPress啦! 转载请注明出处。

#1
辛苦了!翻译这么多。
#2
期待新版本的早日推出。期待新版本能解决2.7.1中的邮局配置问题。
#3
刚才查了一下,2.8里并没有改进邮局设置的计划,目前解决这个问题还是只能用插件。