【发布时间】：2026-02-23 21:40:01
【问题描述】：
我看到有a few。哪些维护且易于使用？他们的优点和缺点是什么？
【问题讨论】：
-
如果您还有兴趣，请查看 Tank Auth。我刚刚在审查后更新了我的帖子，它非常好。
标签： php codeigniter authentication
【发布时间】：2026-02-23 21:40:01
【问题描述】：
更新（2010 年 5 月 14 日）：
事实证明，俄罗斯开发人员 Ilya Konyukhov 在阅读本文后拿起了挑战，并按照以下建议和要求为基于 DX Auth 的 CI 创建了一个新的身份验证库。
由此产生的 Tank Auth 看起来像是 OP 问题的答案。我将在这里冒险并称 Tank Auth 为当今可用的 CodeIgniter 的最佳身份验证库。这是一个坚如磐石的库，具有您需要的所有功能，并且没有您不需要的臃肿：
坦克认证
优点
- 功能齐全
- 考虑到功能集的精简足迹（20 个文件）
- 非常好的文档
- 简单而优雅的数据库设计（只有 4 个数据库表）
- 大多数功能都是可选的并且易于配置
- 语言文件支持
- 支持验证码
- 与 CI 的验证系统挂钩
- 激活电子邮件
- 使用电子邮件、用户名或两者登录（可配置）
- 未激活的帐户自动过期
- 简单而有效的错误处理
- 使用 phpass 进行散列（并且还散列数据库中的自动登录代码）
- 不使用安全问题
- 用户和个人资料数据的分离非常好
- 围绕失败登录尝试的非常合理的安全模型（对机器人和 DoS 攻击的良好保护）
（次要）缺点
- 丢失的密码代码不会在 DB 中散列
- 包含原生（较差的）验证码，这对于那些不想依赖（Google 拥有的）reCAPTCHA 服务的人来说非常有用，但它确实不够安全
- 非常稀少的在线文档（这里的小问题，因为代码记录良好且直观）
原答案：
我也实现了自己的（目前大约 80% 经过几周的工作完成）。我先尝试了所有其他方法； FreakAuth Light、DX Auth、Redux、SimpleLogin、SimpleLoginSecure、pc_user、Fresh Powered 等等。它们都达不到标准，IMO，要么缺乏基本功能，要么天生不安全，要么太臃肿，不符合我的口味。
实际上，我在测试 CodeIgniter 的所有身份验证库时（就在新年之后）对它们进行了详细的汇总。 FWIW，我将与您分享：
DX 认证
优点
- 功能非常齐全
- 中等占用空间（超过 25 个文件），但感觉很苗条
- 优秀的文档，虽然有些英文有点破
- 语言文件支持
- 支持验证码
- 与 CI 的验证系统挂钩
- 激活电子邮件
- 未激活的帐户自动过期
- 建议 grc.com 获取盐（对于 PRNG 来说还不错）
- 禁止使用存储的“原因”字符串
- 简单而有效的错误处理
缺点
- 仅允许用户“重置”丢失的密码（而不是让他们在重新激活时选择新密码）
- Homebrew 伪事件模型 - 善意，但没有达到目标
- 用户表中有两个密码字段，样式不好
- 使用两个单独的用户表（一个用于“临时”用户 - 模棱两可且冗余）
- 使用可能不安全的 md5 散列
- 仅通过 IP 而非用户名存储的失败登录尝试 - 不安全！
- 自动登录密钥未在数据库中散列 - 实际上与以明文形式存储密码一样不安全！
- 角色系统一团糟：is_admin 函数带有硬编码的角色名称，is_role 一团糟，check_uri_permissions 一团糟，整个权限表是个坏主意（URI 可以更改并呈现不受保护的页面；权限应始终准确存储在敏感逻辑所在的位置）。破坏交易！
- 包括本地（差）验证码
- reCAPTCHA 功能界面凌乱
FreakAuth 灯
优点
- 功能非常齐全
- 大部分记录良好的代码
- 用户和个人资料数据的分离是一个很好的接触
- 与 CI 的验证系统挂钩
- 激活电子邮件
- 语言文件支持
- 积极开发
缺点
- 感觉有点臃肿（50+ 个文件）
- 但它缺少自动 cookie 登录 (!)
- 不支持同时使用用户名和电子邮件登录
- 似乎 UTF-8 字符有问题
- 需要大量自动加载（影响性能）
- 严重的微管理配置文件
- 糟糕的视图-控制器分离，视图中有大量程序逻辑，输出硬编码到控制器中。破坏交易！
- 包含的视图中的 HTML 代码不佳
- 包括不合格的验证码
- 评论调试回显无处不在
- 强制使用特定的文件夹结构
- 强制使用特定的 Ajax 库（可以切换，但一开始就不应该存在）
- 登录尝试没有最大限制 - 非常不安全！破坏交易！
- 劫持表单验证
- 使用可能不安全的 md5 散列
pc_user
优点
- 体积小，功能强大
- 轻量级，不臃肿（3 个文件）
- 优雅的自动cookie登录
- 带有可选的测试实现（触感很好）
缺点
- 使用旧的 CI 数据库语法（不太安全）
- 不与 CI 的验证系统挂钩
- 有点不直观的状态（角色）系统（索引颠倒 - 不切实际）
- 使用可能不安全的 sha1 散列
新鲜动力
优点
- 占用空间小（6 个文件）
缺点
- 缺少很多基本功能。破坏交易！
- 一切都是硬编码的。破坏交易！
Redux / 离子验证
根据the CodeIgniter wiki，Redux 已停产，但 Ion Auth fork 正在发展壮大：https://github.com/benedmunds/CodeIgniter-Ion-Auth
Ion Auth 是一个功能完善的库，不会过于繁重或不够先进。在大多数情况下，它的功能集不仅可以满足项目的要求。
优点
- 轻量级且易于与 CodeIgniter 集成
- 支持直接从库发送邮件
- 有据可查的在线文档和良好的活跃开发者/用户社区
- 易于实施到项目中
缺点
- 比其他一些更复杂的数据库架构
- 文档在某些方面缺乏详细信息
SimpleLoginSecure
优点
- 占用空间小（4 个文件）
- 极简主义，绝对不臃肿
- 使用 phpass 进行散列（优秀）
缺点
- 仅登录、注销、创建和删除
- 缺少很多基本功能。破坏交易！
- 更多的是起点而不是图书馆
不要误会我的意思：我并不是要不尊重上述任何库；我对他们的开发人员所取得的成就以及他们每个人所取得的成就印象深刻，而且我并没有放弃重用他们的一些代码来构建我自己的代码。我的意思是，有时在这些项目中，重点从基本的“必备”（例如硬安全实践）转移到更软的“必备”，这就是我希望解决的问题.
因此：回归基础。
CodeIgniter 的身份验证已完成正确
这是我的身份验证库中所需的最少功能列表。它也恰好是我自己图书馆功能列表的一个子集；）
- 占用空间小，可选测试实施
- 完整文档
- 不需要自动加载。即时加载库以提高性能
- 语言文件支持；没有硬编码的字符串
- 支持 reCAPTCHA，但可选
- 推荐的 TRUE 随机盐生成（例如使用 random.org 或 random.irb.hr）
- 支持第 3 方登录的可选插件（OpenID、Facebook Connect、Google 帐户等）
- 使用用户名或电子邮件登录
- 分离用户和个人资料数据
- 用于激活和丢失密码的电子邮件
- cookie 自动登录功能
- 可配置的 phpass 用于散列（当然要适当加盐！）
- 密码散列
- 自动登录代码的散列
- 丢失密码代码的散列
- 与 CI 的验证系统挂钩
- 没有安全问题！
- 在服务器端强制执行强密码策略，带有可选的客户端 (Javascript) 验证器
- 使用最佳实践对策针对字典和 DoS 攻击强制登录尝试失败的最大次数！
- 所有数据库访问都通过准备好的（绑定的）语句完成！
注意：最后几点不是您的 Web 应用程序不需要的超高安全性过度杀伤力。 如果身份验证库不能 100% 满足这些安全标准，请不要使用它！
最近备受瞩目的不负责任的程序员将他们排除在软件之外的例子：#17 是 Sarah Palin 的 AOL 电子邮件在总统竞选期间被黑客入侵的原因；最近，当布兰妮斯皮尔斯、巴拉克奥巴马、福克斯新闻和其他人的推特账户被黑客入侵时，#18 和 #19 的令人讨厌的组合是罪魁祸首；仅第 20 条就是中国黑客如何在 2008 年的一次自动黑客攻击中成功地从 70,000 多个韩国网站窃取了 900 万条个人信息。
这些攻击不是脑部手术。如果你让你的后门敞开着，你不应该通过栓上前门来欺骗自己，从而产生一种虚假的安全感。此外，如果您对编码足够认真，可以选择像 CodeIgniter 这样的最佳实践框架，那么您应该至少正确地完成最基本的安全措施。
基本上，它是这样的：我不在乎如果一个身份验证库提供了一堆功能、高级角色管理、PHP4 兼容性、漂亮的 CAPTCHA 字体、国家表、完整的管理面板，花里胡哨的 -- 如果图书馆没有遵循最佳实践，实际上使我的网站不那么安全。这是一个身份验证包；它需要正确地做一件事：身份验证。如果它没有做到那，它实际上弊大于利。
/詹斯·罗兰
【讨论】：
-
Jens，您可能想看看 Tank Auth，它似乎是为响应您的（出色）帖子而创建的：codeigniter.com/forums/viewthread/110993
-
你能更新这篇文章并与Ion-Auth（源自dx-auth）进行比较吗？在这个时间点上，似乎 ion-auth 比 tank-auth 更新和活跃。我想从安全角度了解它是否与 Tank-auth 一样好，因为它具有一些可能有用的附加功能。
-
所有这些库都使用 mysql.. 但是我使用 MongoDb 这是一个 noSql 数据库。是否有与 MoongoDB 一起使用的库？我尝试将上面的库之一转换为插入 MongoDB 而不是 MySql，但它变得太复杂了，我想知道一个已经这样做的库
-
@Lykos：当然——用户数据将是特定于身份验证的数据，例如 UserID、UserName、Email、PasswordHash、LastLoginTime 等。配置文件数据应存储在单独的数据库表中，可以是任何数据，取决于具体的应用。这可能包括生日、性别、家乡、声誉分数等。这样，应用程序开发人员可以以他们喜欢的任何方式修改 ProfileData 表，而不必担心身份验证系统突然崩溃。
请注意，Jens Roland 的“综合列表”不包括用户角色。如果您有兴趣分配不同的用户角色（如 admin/user 或 admin/editor/user），这些库允许：
- Ion_Auth（重写 Redux）
- Redux
- 后端专业版
Tank_Auth（Jens 列表中的第一名）没有用户角色。我意识到这不完全是身份验证的一部分，但因为
- 身份验证和角色管理均在页面加载时处理
- 两者都涉及安全
- 相同的表/模型可用于两者。
- 两者都可以设置为在控制器构造函数中加载（甚至自动加载）
如果您需要，拥有一个库来处理两者是很有意义的。因此，我从 Tank_Auth 切换到 Ion_Auth。
【讨论】：
-
Ion_Auth 与 CI 2.1 和 DataMapper ORM 完美配合
Ion_auth！看起来很有前途，而且占地面积小！我喜欢..
【讨论】：
-
Ion Auth 对我来说也很好用，有我需要的一切，没有我不需要的东西（比如秘密问题等）。
-
Ion Auth 在使用、功能和轻量化方面看起来像当前的领导者。
-
我已经尝试过 Tank Auth 和 Ion Auth，我可以说 Tank Auth 代码比 Ion Auth 更简洁、更易于理解和更易于扩展。另一方面，Ion Auth 支持“角色”。
我是 Redux Auth 的开发人员，您提到的一些问题已在版本 2 测试版中得到修复。您也可以通过示例应用程序从官方网站下载此内容。
- 需要自动加载（影响性能）
- 使用“安全问题”的固有不安全概念。破坏交易！
现在不使用安全问题，并建立了一个更简单的忘记密码系统。
- 返回类型有点像真、假、错误和成功代码的大杂烩
这在版本 2 中已修复并返回布尔值。我和你一样讨厌大杂烩。
- 不与 CI 的验证系统挂钩
示例应用程序使用 CI 的验证系统。
- 不允许用户重新发送“丢失的密码”代码
进行中
我还实现了一些其他功能，例如电子邮件视图，这使您可以选择在电子邮件中使用 CodeIgniter 帮助程序。
这项工作仍在进行中，所以如果有更多建议，请继续提出。
-爆米花
Ps : 感谢推荐 Redux。
【讨论】：
-
刚刚快速浏览了 CI 论坛主题和路线图。看起来不错 - 关于“动态”盐，我建议连接 (reg. date) 。 （配置文件哈希键）。 （代码或密码）来阻止彩虹表和对被盗数据库的暴力破解
-
另外，我对 auth 最佳实践 (*.com/questions/549/…) 和僵尸网络节流 (*.com/questions/479233/…) 有一些想法，您可能想跳过
我遇到了 Flexi Auth (http://haseydesign.com/flexi-auth/)。它看起来很有前途，我已经开始使用它了。它具有奇妙的功能。与 CI 完全集成，并带有两个不同的库文件，其中一个非常重载所有功能，另一个仅包含验证。
最好的方法之一是新注册的会员可以在给定的时间内临时访问网站，直到他们点击电子邮件中的链接并激活。
【讨论】：
-
感谢您提供此链接。它还有另一个很好的功能 Flexi Cart haseydesign.com/flexi-cart .
也许您会发现Redux 适合您的需求。这并不过分，而且仅包含我们大多数人需要的基本功能。开发人员和贡献者对贡献的代码非常严格。
【讨论】：
-
Redux 维护时间更长，请参阅此讨论。 codeigniter.com/forums/viewthread/145342
-
Ion Auth 基于 Redux Auth 2，我会使用它。 PyroCMS 也使用它。 github.com/benedmunds/CodeIgniter-Ion-Auth
Ion_Auth 击败 tank_auth 主要有两个原因，用户角色和文档，tank_auth 缺少这两个。
【讨论】：
我使用自定义版本的DX Auth。我发现它使用简单，非常容易修改，并且它有一个与 Code Igniter 非常相似的user guide (with great examples)。
【讨论】：
也可以看看BackendPro
最终你可能会写一些自定义的东西，但是从 DX Auth、Freak Auth、BackendPro 等借用概念并没有错。
我对打包应用程序的经验是它们特定于某些结构，并且我在将它们集成到我自己的应用程序中而不需要破解时遇到了问题，那么如果预包有更新，我必须将它们迁移进去。
我还在我的 CI 代码中使用 Smarty 和 ADOdb，所以无论如何我最终都会对代码进行重大更改。
【讨论】：
Tank Auth 看起来不错，但文档只是关于如何安装的一页说明，以及每个 PHP 文件的快速运行。至少这就是我在大量谷歌搜索后发现的全部。当人们说 Tank Auth 有据可查时，也许上面的意思是代码有很好的注释。这是一件好事，但与文档不同。如果有一些关于如何将 Tank Auth 的功能与现有代码集成的文档，那就太好了。
【讨论】：
我正在尝试 Ion_Auth 并感谢它，顺便说一句...
SimpleLoginSecure 使身份验证简单而安全。
【讨论】：