在大多数其他框架中，你不得不自己创建页面控制器去处理身份验证过程。在Solar中，事情就不是这样了；而在Solar中，处理登陆和注销请求的逻辑都被封装在Solar_Auth_Adapter类中。配置好适配器且确保它能识别登陆和注销尝试后，适配器将会拦截传入的请求并且自动处理这个过程。
![[Note]](images/note.png) | Note |
|---|---|
|
如果因为某些原因，你想建立单独的身份验证控制器，你可以这么做，但是，通常来说，你不需要这么做。 |
Solar提供不同的适配器允许使有几种认证方法。Solar现有的适配器如下：
-
Solar_Auth_Adapter_Htpasswd － 使用htpasswd产生的文件验证。
-
Solar_Auth_Adapter_Ini － 使用.ini风格的文件验证。
-
Solar_Auth_Adapter_Ldap － 使用LDAP服务器验证。
-
Solar_Auth_Adapter_None － 不使用任何东西验证，默认所有验证失败。
-
Solar_Auth_Adapter_Post － 通过简单的HTTP POST 请求和回复验证。
-
Solar_Auth_Adapter_Sql － 使用SQL数据库表验证。
-
Solar_Auth_Adapter_Typekey － TypeKey的验证适配器。
| Note |
|---|---|
|
注意，这些适配器都是只读的。它们不会为你管理和创建用户帐户，它们仅仅把传入的用户证明信息和已存储的信息做比较。 |
Solar使用Solar_Auth工厂类创建适配器实例，所以你要配置工厂类以使其创建你期望的验证适配器。在配置文件中，像这样操作：
<?php
$config['Solar_Auth'] = array(
'adapter' => 'Solar_Auth_Adapter_Sql',
);
现在我们已经告诉工厂类需要创建哪个适配器了，我们还需要配置适配器自身。所有适配器具有相同的基本配置项，虽然每个适配器也有一些自己的附加设置。
下面是验证适配器相同的基本配置项：
expire-
(int) 一次身份验证持续的生命期，以秒为单位。生命期过后，用户将被强制注销而且必须再次登陆。0代表永远不过期，默认是14400秒（4小时）。如果这个值大于php.ini文件中配置项`session.cookie_lifetime`的值，将会抛出异常。
idle-
(int) 允许的最大空闲时间，以秒为单位。如果用户空闲时间超过这个值，那么用户将会被注销并且不得不再次登陆。0代表允许的空闲时间为无穷大。默认值是1440秒（24分钟）。如果这个值大于php.ini文件中配置项`session.gc_maxlifetime`的值，将会抛出异常。
source-
(string) 验证凭据源数组，取值为
'get'（通过$_GET[]请求变量）或'post'（通过$_POST[]请求变量）。默认是'post'。 source_handle-
(string) 在验证凭据源数组中用户名对应的键名，默认为
handle。 source_passwd-
(string) 在验证凭据源数组中密码对应的键名，默认为
passwd。 source_redirect-
(string) 验证凭据源数组无素的键，指示当用户成功登陆或注销时页面转向哪里，默认为
'redirect'。 source_process-
(string) 验证凭据源数组无素的键，指示如何处理用户请求，默认为
'process'。 process_login-
(string)
source_process元素的值，标示一次登陆请求；默认是'PROCESS_LOGIN'指示的本地字符串值，即'login'。 process_logout-
(string)
source_process元素的值，标示一次注销请求；默认是'PROCESS_LOGOUT'指示的本地字符串值，即'logout'。 login_callback-
(callback) 登陆过程的一部分，无论登陆成功与否，执行此回调函数。
logout_callback-
(callback) 注销过程的一部分，注销结束后，执行此回调函数。
基于以上的默认设置，我们能够察觉到：
-
当
$_POST['process'] == 'login'条件为真时，适配器将会处理一次登陆请求。当它验证适配器独有的存储凭据时，使用$_POST['handle']的值作为用户名，$_POST['passwd']的值作为明文密码。 -
当
$_POST['process'] == 'logout'条件为真时，适配器将会处理一次注销请求。 -
在一次成功登陆或注销后，适配器将会查看
$_POST['redirect']的值，如果非空，将会转向到指定的URI。
除了上面提到的适配器的公共配置外，每个适配器还有针对凭据存储后端独有的配置。
在上面的示例中，我们使用了Solar_Auth_Adapter_Sql适配器。你可以在这里看到所有配置项的联合集，我们现在来看看其中的一些配置：
sql-
(dependency)
Solar_Sql类依赖注入。这个注入给适配器一个SQL数据库连接。默认为'sql'，意味着适配器将会在对象注册表中寻找名为sql的对象。 table-
(string) 数据库表名，带有用户名和密码。默认为
'members'。 handle_col-
(string) 数据表中用户名字段。默认是
'handle'。 passwd_col-
(string) 数据表中密码（哈希处理后）字段。默认是
'passwd'。 hash_algo-
(string) 用于密码的哈希算法。默认是
'md5'。 salt-
(string) 密码被哈希处理之前的前缀字符串。默认为空。
例如，如果你想使用对象注册表中的'sql'对象提供数据库连接（users.handle和users.password作为表字段），使用sha1哈希算法处理密码，你应该在配置文件中添加这些条目：
<?php
$config['Solar_Auth_Adapter_Sql'] = array(
'sql' => 'sql',
'table' => 'users',
'handle_col' => 'handle',
'passwd_col' => 'password',
'hash_algo' => 'sha1'
);
同样地，每个适配器都有自己独有的配置，要了解更多相关内容请查看API文档。
建立身份验证最困难的部分是配置部分。一旦正确地完成了配置部分，剩下的只需要创建Solar_User的实例，你可以自己创建这个实例也可以从对象注册表中获取它。Solar_User对象会自动创建Solar_Auth实例并且自动开始身份验证过程、自动处理登陆和注销请求。
| Note |
|---|---|
|
要想知道验证的背后到底发生了什么，请查看 |
假设我们使用SQL角色适配器读取roles数据表，假设表中有如下信息：
# table: members handle passwd -------- ---------- bolivar **** andy **** sarah **** jameel **** kornblum ****
我们再假设用户'andy'已经登陆了。Solar_User对象内部含有Solar_Auth_Adapter实例，所以当我们实例化它后，它会为我们处理用户登陆请求。之后我们可以使用Solar_Auth_Adapter对象的方法和属性来找出Andy的身份证明。（别忘了，我们使用的是Solar_User对象，而不需要单独实例化一个验证适配器。）
