我应该如何为CodeIgniterselect一个authentication库？
我看到有几个 。 哪些维护和易于使用？ 他们有什么优点和缺点？
更新（2010年5月14日）：
事实certificate，俄罗斯开发人员Ilya Konyukhov在阅读完这篇文章之后拿起了这本手册，并根据下面的build议和要求为基于DX Auth的CI创build了一个新的auth库。
由此产生的坦克authentication看起来像OP的问题的答案。 我将在这里出去，并将Tank Auth称为CodeIgniter当前可用的最佳authentication库。 这是一个坚如磐石的图书馆，它具有你所需要的所有function，而且你没有那么多的臃肿：
坦克authentication
优点
- 全function
- 精益足迹（20个文件）考虑function集
- 非常好的文档
- 简单和优雅的数据库devise（只有4个数据库表）
- 大多数function是可选的，并且configuration简单
- 语言文件支持
- reCAPTCHA支持
- 钩入CI的validation系统
- 激活电子邮件
- 用电子邮件，用户名或两者login（可configuration）
- 未激活的帐户自动失效
- 简单而有效的error handling
- 使用phpass进行哈希（并在数据库中哈希自动编码）
- 不使用安全问题
- 分离用户和configuration文件数据是非常好的
- 失败的login尝试周围的非常合理的安全模式（防止机器人和DoS攻击）
（次要）缺点
- 丢失的密码不在数据库中散列
- 包括一个本地（可怜的）CAPTCHA，这对那些不想依赖（Google拥有的）reCAPTCHA服务的人来说很好，但是它确实不够安全
- 非常稀less的在线文档（这里的小问题，因为代码是很好的logging和直观）
在这里下载坦克authentication
原始答案：
我已经实施了自己的工作（目前约80％的工作几个星期后）。 我先尝试了所有其他人 FreakAuth Light，DX Auth，Redux，SimpleLogin，SimpleLoginSecure，pc_user，Fresh Powered等等。 国际海事组织无一例外，他们都缺乏基本特征，本质上不安全，或者我的口味太臃肿。
实际上，当我testing了CodeIgniter的所有authentication库之后（刚刚过年），我做了一个详细的综述。 FWIW，我会与你分享：
DXauthentication
优点
- 非常全function
- 中等足迹（25 +文件），但设法感到相当苗条
- 优秀的文件，虽然有些是英文稍微破碎
- 语言文件支持
- reCAPTCHA支持
- 钩入CI的validation系统
- 激活电子邮件
- 未激活的帐户自动失效
- build议grc.com盐（对PRNG不坏）
- 禁止存储“原因”string
- 简单而有效的error handling
缺点
- 只允许用户“重置”丢失的密码（而不是让他们在重新激活时select一个新密码）
- 自制的伪事件模型 – 好意，但错过了标志
- 用户表中有两个密码字段，风格不好
- 使用两个单独的用户表（一个用于“临时”用户 – 模糊和冗余）
- 使用潜在的不安全的md5散列
- 失败的login尝试仅通过IP存储，而不是通过用户名 – 不安全！
- 自动login密钥不在数据库中散列 – 实际上与以明文方式存储密码一样不安全！
- angular色系统是一个完整的混乱：is_admin函数与硬编码的angular色名称，is_role一个完整的混乱，check_uri_permissions是一团糟，整个权限表是一个坏主意（一个URI可以改变和呈现页面不受保护;权限应始终准确存储敏感逻辑在哪里）。 因素在于！
- 包括一个本地（可怜的）CAPTCHA
- reCAPTCHAfunction界面凌乱
怪物光
优点
- 非常全function
- 大部分文档很好的代码
- 用户和configuration文件数据的分离是一个很好的接触
- 钩入CI的validation系统
- 激活电子邮件
- 语言文件支持
- 积极开发
缺点
- 感觉有点臃肿（50+文件）
- 但它没有自动cookielogin（！）
- 不支持用户名和电子邮件login
- 似乎有UTF-8字符的问题
- 需要大量的自动加载（阻碍性能）
- 微不足道的configuration文件
- 可怕的View-Controller分离，在视图中有许多程序逻辑，输出硬编码到控制器中。 因素在于！
- 包含的视图中的HTML代码很差
- 包括不合格的CAPTCHA
- 评论debugging回声随处可见
- 强制特定的文件夹结构
- 强制一个特定的Ajax库（可以切换，但不应该在那里）
- login尝试没有最大限制 – 非常不安全！ 因素在于！
- 劫持表单validation
- 使用潜在的不安全的md5散列
pc_user
优点
- 良好的function设置为其小脚印
- 轻量级，没有膨胀（3个文件）
- 优雅的自动cookielogin
- 来自可选的testing实施（好触摸）
缺点
- 使用旧的CI数据库语法（不太安全）
- 不挂钩到CI的validation系统
- 有点不直观的地位（angular色）系统（索引颠倒 – 不切实际）
- 使用潜在的不安全sha1散列
新鲜的动力
优点
- 占地面积小（6个文件）
缺点
- 缺乏很多必要的function。 因素在于！
- 一切都是硬编码的。 因素在于！
Redux / Ion Auth
根据CodeIgniter wiki ，Redux已经停产了，但是Ion Auth的分支已经很强大了： https ： //github.com/benedmunds/CodeIgniter-Ion-Auth
Ion Auth是一个function完善的图书馆，没有过于沉重或欠缺。 在大多数情况下，它的function集不仅仅满足项目需求。
优点
- 轻量级且易于与CodeIgniter集成
- 支持直接从图书馆发送电子邮件
- 有良好的在线文档和良好的活跃开发/用户社区
- 很容易实现一个项目
缺点
- 比其他一些更复杂的数据库模式
- 文档在某些领域缺乏细节
SimpleLoginSecure
优点
- 小脚印（4个文件）
- 简约，绝对没有膨胀
- 使用phpass进行哈希（优秀）
缺点
- 只有login，注销，创build和删除
- 缺乏很多必要的function。 因素在于！
- 比图书馆更多的一个起点
不要误解我的意思：我不是不尊重上述任何一个图书馆; 我对他们的开发人员所取得的成就感到非常满意，他们每个人的成就都很高，而且我还没有重复使用他们的一些代码来构build自己的代码。 我所说的是，有时在这些项目中，焦点从“必须拥有”（比如硬性安全实践）转移到更加“柔弱”的软件，这就是我希望能够弥补的。
因此：回到基础。
CodeIgniter的authentication正确
这是我的MINIMAL必需的authentication库中的function列表。 它也恰好是我自己的图书馆的function列表的一个子集;）
- 微小的足迹与可选的testing实施
- 完整的文档
- 不需要自动加载。 即时加载库的性能
- 语言文件支持; 没有硬编码的string
- reCAPTCHA支持，但可选
- 推荐的TRUE随机盐生成（例如使用random.org或random.irb.hr）
- 可选附件支持第三方login（OpenID，Facebook Connect，Google帐户等）
- 使用用户名或电子邮件login
- 分离用户和configuration文件数据
- 用于激活和丢失密码的电子邮件
- 自动cookieloginfunction
- 哈希的可configuration的phpass（当然适当地盐渍！）
- 散列密码
- 散列自动编码
- 散列密码丢失
- 钩入CI的validation系统
- 没有安全问题！
- 强制密码策略服务器端，与可选的客户端（Javascript）validation
- 实施最大数量的失败login尝试与最佳实践对付字典和DoS攻击的对策 ！
- 所有数据库访问通过准备（绑定）语句完成！
注意：最后几点并不是您的Web应用程序所不需要的超高安全性的矫枉过正。 如果authentication库不符合这些安全标准100％，请不要使用它！
最近引人瞩目的不负责任的编码人员的例子，他们把他们从软件中排除在外：＃17是萨拉·佩林的AOL电子邮件在总统竞选期间如何被黑客攻击; 最近，当Britney Spears，Barack Obama，Fox News等人的Twitter帐号被黑客攻击时，＃18和＃19的恶意组合是罪魁祸首。 仅仅是＃20就是中国黑客在2008年以一次自动黑客的方式从70多万韩国网站窃取了900万条个人信息。
这些攻击不是脑部手术。 如果你把后门敞开的话，你不应该把前面的螺栓钉在一个错误的安全感上。 而且，如果你对编码selectCodeIgniter这样的最佳实践框架认真，那么你应该至less得到最基本的安全措施。
<咆哮>
基本上，这是如何实现的： 我不关心 auth库是否提供了一些function，高级angular色pipe理，PHP4兼容性，漂亮的CAPTCHA字体，国家表格，完整的pipe理面板，花里胡哨的 – 如果库实际上我的网站由于不遵循最佳实践而不太安全 。 这是一个authentication包; 它需要做一件事：身份validation。 如果不这样做的话 ，那实际上是在弊大于利。
</咆哮>
/ Jens Roland
请注意，Jens Roland的“综合列表”不包括用户angular色。 如果您有兴趣分配不同的用户angular色（如admin / user或admin / editor / user），这些库允许：
- Ion_Auth（重写Redux）
- 终极版
- 后端Pro
Tank_Auth（Jens列表中的＃1）没有用户angular色。 我意识到这不完全是authentication的一部分，但从那时起
- 身份validation和angular色pipe理都是在页面加载时处理的
- 两者都涉及安全
- 两个表格可以使用相同的表格/模型。
- 两者都可以设置为在控制器构造函数中加载（甚至自动加载）
如果你需要的话，有一个图书馆可以同时处理这两个图书馆。 因为这个，我从Tank_Auth切换到Ion_Auth。
Ion_auth！ 看起来非常有前途，占地面积小！ 我喜欢..
我是Redux Auth的开发人员，你提到的一些问题已经在第2版testing版中修复了。 您也可以通过示例应用程序从官方网站下载。
- 需要自动加载（阻碍性能）
- 使用“安全问题”固有的不安全的概念。 因素在于！
现在没有使用安全问题，而且更简单的忘记密码系统已经到位。
- 返回types是一个真正的，错误的，错误和成功代码大杂烩
这是在版本2中修复的，并返回布尔值。 我和你一样讨厌大杂烩。
- 不挂钩到CI的validation系统
示例应用程序使用CI的validation系统。
- 不允许用户重新发送“丢失的密码”代码
工作正在进行中
我还实现了一些其他function，如电子邮件视图，这使您可以select在您的电子邮件中使用CodeIgniter助手。
这仍然是一个工作，所以如果有任何更多的build议，请保持他们来。
-爆米花
Ps：感谢您推荐Redux。
也许你会发现Redux适合你的需求。 这不是矫枉过正，只是我们大多数人所需要的裸露function。 开发者和贡献者对代码的贡献非常严格。
这是官方网页
我遇到了Flexi Auth（ http://haseydesign.com/flexi-auth/ ）。 看起来非常有希望，我已经开始使用它了。 它有奇特的function。 与CI完全集成，并带有两个不同的库文件，其中一个非常重载所有function，另一个仅包含validation。
其中最好的一点是，新注册的会员可以在网站上获得一段时间的临时访问权限，直到他们点击邮件中的链接并激活。
Ion_Auth主要是因为两个原因，用户angular色和文档，tank_auth中缺less这两个。
我使用DX Auth的定制版本。 我发现使用简单，修改起来非常简单，它有一个与Code Igniter非常相似的用户指南（很好的例子） 。
也看看BackendPro
最终，你可能最终会写一些自定义的东西，但从DX Auth，Freak Auth，BackendPro等借用概念没有任何错误。
我对打包的应用程序的经验是，他们是特定于某些结构，我有问题集成到我自己的应用程序，而不需要黑客，然后如果预包有更新，我必须迁移他们。
我也在我的CI代码中使用了Smarty和ADOdb，所以不pipe我总是最终做出重大的代码更改。
坦克authentication看起来不错，但文档只是一个单页的解释如何安装，加上每个PHP文件的快速运行。 至less这是我search了很多谷歌search之后。 也许当人们认为坦克authentication是有据可查的时候，上面的意思就是代码是很好的评论。 这是一件好事，但与文档不同。 如果有关于如何将Tank Auth的function与现有的代码整合的文档，本来就不错。
我正在尝试Ion_Auth，并欣赏它，顺便说一句…
SimpleLoginSecure使authentication简单而安全。
