我看有几个。哪些维护且易于使用？他们的优点和缺点是什么？
优点 全功能 考虑到功能集的精益足迹（20 个文件） 非常好的文档 简洁优雅的数据库设计（仅 4 个 DB 表） 大多数功能都是可选的并且易于配置 语言文件支持 支持 reCAPTCHA 与 CI 的验证系统挂钩 激活电子邮件 使用电子邮件、用户名或两者登录（可配置） 未激活帐户自动过期 简单而有效的错误处理 使用 phpass 进行散列（也散列数据库中的自动登录代码） 不使用安全问题 用户和配置文件数据的分离非常好 围绕失败登录尝试的非常合理的安全模型（对机器人和 DoS 攻击的良好保护） （次要）缺点 丢失的密码代码不会在 DB 中散列 包括一个本地（差）验证码，这对于那些不想依赖（谷歌拥有的）reCAPTCHA 服务的人来说很好，但它确实不够安全 非常稀少的在线文档（这里的小问题，因为代码记录良好且直观）
优点
（次要）缺点
在此处下载 Tank Auth
原答案：
我也实现了自己的（目前大约 80% 经过几周的工作完成）。我先尝试了所有其他方法；FreakAuth Light、DX Auth、Redux、SimpleLogin、SimpleLoginSecure、pc_user、Fresh Powered 等等。它们都达不到标准，IMO，要么缺乏基本功能，要么天生不安全，要么太臃肿，不符合我的口味。
实际上，当我测试 CodeIgniter 的所有身份验证库时（就在新年之后），我对它们进行了详细的汇总。FWIW，我将与您分享：
优点 功能很全 中等占用空间（超过 25 个文件），但感觉很苗条 优秀的文档，虽然有些是英文略显蹩脚的 语言文件支持 支持 reCAPTCHA 与 CI 的验证系统挂钩 激活电子邮件 未激活帐户自动过期 建议 grc.com 使用盐（对于 PRNG 来说还不错） 禁止使用存储的“原因”字符串 简单而有效的错误处理 缺点 只允许用户“重置”丢失的密码（而不是让他们在重新激活时选择一个新密码） Homebrew 伪事件模型 - 善意，但未达标 用户表中有两个密码字段，样式不好 使用两个单独的用户表（一个用于“临时”用户 - 模棱两可且冗余） 使用可能不安全的 md5 散列 失败的登录尝试仅由 IP 存储，而不是由用户名存储 - 不安全！ 自动登录密钥未在数据库中散列 - 实际上与以明文形式存储密码一样不安全！ 角色系统一团糟：is_admin 函数带有硬编码的角色名称，is_role 一团糟，check_uri_permissions 是一团糟，整个权限表是个坏主意（URI 可以更改并使页面不受保护；权限应始终准确存储敏感逻辑在哪里）。破坏者！ 包括本地（差）验证码 reCAPTCHA 功能界面凌乱
缺点
优点 功能很全 大部分是有据可查的代码 用户和配置文件数据的分离是一个很好的接触 与 CI 的验证系统挂钩 激活电子邮件 语言文件支持 积极开发 缺点 感觉有点臃肿（50+ 文件） 然而它缺乏自动cookie登录（！） 不支持同时使用用户名和电子邮件登录 似乎有 UTF-8 字符的问题 需要大量自动加载（阻碍性能） 糟糕的微管理配置文件 可怕的视图-控制器分离，视图中有很多程序逻辑，输出硬编码到控制器中。破坏者！ 包含的视图中的 HTML 代码不佳 包括不合格的验证码 评论调试回声无处不在 强制使用特定的文件夹结构 强制一个特定的 Ajax 库（可以切换，但首先不应该在那里） 登录尝试没有最大限制 - 非常不安全！破坏者！ 劫持表单验证 使用可能不安全的 md5 散列
优点 占地面积小，功能强大 轻巧，不臃肿（3个文件） 优雅的自动cookie登录 带有可选的测试实现（很好的接触） 缺点 使用旧的 CI 数据库语法（不太安全） 不与 CI 的验证系统挂钩 有点不直观的状态（角色）系统（索引颠倒 - 不切实际） 使用可能不安全的 sha1 散列
优点 占用空间小（6 个文件） 缺点 缺少很多基本功能。破坏者！ 一切都是硬编码的。破坏者！
根据CodeIgniter wiki，Redux 已经停产，但 Ion Auth 分支正在变得强大：https ://github.com/benedmunds/CodeIgniter-Ion- Auth
Ion Auth 是一个功能齐全的库，不会过于繁重或不够先进。在大多数情况下，它的功能集将不仅仅满足项目的要求。
优点 轻量级且易于与 CodeIgniter 集成 支持直接从图书馆发送电子邮件 有据可查的在线和良好的活跃开发/用户社区 易于实施到项目中 缺点 比其他一些更复杂的数据库模式 文档在某些领域缺乏细节
优点 占地面积小（4 个文件） 极简主义，绝对不臃肿 使用 phpass 进行散列（优秀） 缺点 仅登录、注销、创建和删除 缺少很多基本功能。破坏者！ 比图书馆更多的起点
不要误会我 的意思：我并不是要不尊重上述任何图书馆；我对他们的开发人员所取得的成就以及他们每个人所取得的成就印象深刻，而且我并没有放弃重用他们的一些代码来构建我自己的代码。我的意思是，有时在这些项目中，重点从基本的“必备”（例如硬安全实践）转移到更软的“必备”，这就是我希望解决的问题.
因此：回归基础。
这是我的身份验证库中所需的最小功能列表。它也恰好是我自己图书馆功能列表的一个子集；）
具有可选测试实施的小尺寸 完整的文档 无需自动加载。即时加载库以提高性能 语言文件支持；没有硬编码的字符串 支持 reCAPTCHA 但可选 推荐的 TRUE 随机盐生成（例如使用 random.org 或 random.irb.hr） 支持 3rd 方登录的可选附加组件（OpenID、Facebook Connect、Google 帐户等） 使用用户名或电子邮件登录 分离用户和个人资料数据 用于激活和丢失密码的电子邮件 自动cookie登录功能 用于散列的可配置 phpass（当然要适当加盐！） 密码散列 自动登录代码的散列 散列丢失的密码代码 与 CI 的验证系统挂钩 没有安全问题！ 强制的强密码策略服务器端，带有可选的客户端 (Javascript) 验证器 使用针对字典和 DoS 攻击的 最佳实践对策 强制登录尝试失败的最大次数！ 所有数据库访问都是通过准备好的（绑定的）语句完成的！
注意：最后几点 并不是 您的 Web 应用程序不需要的超高安全性矫枉过正。 如果身份验证库不能 100% 满足这些安全标准，请不要使用它！
最近备受瞩目的不负责任的程序员将他们排除在软件之外的例子：#17 是 Sarah Palin 的 AOL 电子邮件在总统竞选期间被黑客入侵的原因；最近，当布兰妮斯皮尔斯、巴拉克奥巴马、福克斯新闻和其他人的推特账户被黑客入侵时，#18 和 #19 的令人讨厌的组合是罪魁祸首；仅 #20 就是中国黑客如何在 2008 年的一次自动黑客攻击中成功地从 70,000 多个韩国网站窃取了 900 万条个人信息。
这些攻击不是脑部手术。如果你让你的后门敞开着，你不应该通过栓上前门来欺骗自己，从而产生一种虚假的安全感。此外，如果您对编码足够认真，可以选择像 CodeIgniter 这样的最佳实践框架，那么您应该至少正确完成 最基本 的安全措施。
<咆哮>
基本上，它是这样的： 我不在乎 一个 auth 库是否提供了一堆功能、高级角色管理、PHP4 兼容性、漂亮的 CAPTCHA 字体、国家表、完整的管理面板、花里胡哨——如果这个库真的让由于不遵循最佳实践，我的网站 的安全性降低。 这是一个 认证 包；它需要正确地做一件事：身份验证。如果它没有做到 这一点 ，它实际上弊大于利。
/延斯·罗兰
