我看到有几。哪些是易于维护和使用的?他们的优点和缺点是什么?
也许你会发现回来的适合你的需要。它并不是多余的，它只包含了我们大多数人都需要的基本功能。开发人员和贡献者对所贡献的代码非常严格。
这是官方页面
我使用了自定义版本的DX身份验证。我发现它使用简单，非常容易修改，它有一个用户指南(有很好的例子)，这是非常类似于代码点燃器的。
再看一下BackendPro
最终你可能会写一些自定义的东西，但从DX Auth, Freak Auth, BackendPro等借用概念并没有错。
我使用打包应用程序的经验是，它们是特定于某些结构的，我在不需要修改的情况下将它们集成到我自己的应用程序中遇到过问题，然后如果预包有更新，我必须将它们迁移进去。
我也在CI代码中使用Smarty和ADOdb，所以无论如何，我最终都会做出重大的代码更改。
事实证明，俄罗斯开发人员Ilya Konyukhov在阅读这篇文章后接受了挑战，并根据下面的建议和要求，为基于DX auth的CI创建了一个新的认证库。
结果Tank Auth看起来像OP的问题的答案。在这里，我将大胆地将Tank Auth称为目前CodeIgniter可用的最佳身份验证库。这是一个坚如磐石的库，拥有所有你需要的功能，没有你不需要的臃肿:
优点 全功能的 精简内存(20个文件)，考虑特性集 非常好的文档 简单而优雅的数据库设计(只有4个DB表) 大多数功能都是可选的，易于配置 语言文件支持 reCAPTCHA支持 连接到CI的验证系统 激活电子邮件 使用电子邮件，用户名或两者登录(可配置) 未激活的帐户自动过期 简单而有效的错误处理 使用phpass进行哈希(也对DB中的自登录代码进行哈希) 不使用安全问题 用户和配置文件数据的分离非常好 对于失败的登录尝试，非常合理的安全模型(对机器人和DoS攻击的良好保护) (小)缺点 丢失的密码代码不会在DB中散列 包括一个原生的(很差的)验证码，这对于那些不想依赖(谷歌拥有的)验证码服务的人来说是很好的，但它确实不够安全 非常少的在线文档(这里的小问题，因为代码有很好的文档和直观)
优点
(小)缺点
下载坦克认证在这里
最初的回答:
我也实现了我自己的(目前在几周的工作后完成了80%)。我先试了所有其他的;FreakAuth Light, DX Auth, Redux, SimpleLogin, SimpleLoginSecure, pc_user, Fresh Powered，等等。在我看来，它们没有一个达到标准，要么缺乏基本功能，本质上不安全，要么对我的口味来说太臃肿了。
实际上，我在测试CodeIgniter的所有身份验证库时(就在新年之后)对它们进行了详细的汇总。FWIW，我将与你分享:
优点 功能非常齐全 中等大小(25个以上的文件)，但感觉相当薄 优秀的文档，尽管有些文档的英文有点蹩脚 语言文件支持 reCAPTCHA支持 连接到CI的验证系统 激活电子邮件 未激活的帐户自动过期 建议grc.com为盐(不坏的PRNG) 禁止与存储'reason'字符串 简单而有效的错误处理 缺点 只允许用户“重置”丢失的密码(而不是让他们重新激活时选择一个新密码) 自制的伪事件模型-好的意图，但没有达到目的 用户表中有两个密码字段，样式不好 使用两个独立的用户表(一个用于'temp'用户-歧义且冗余) 使用可能不安全的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维基, Redux已经停产，但离子认证叉正在强大:https://github.com/benedmunds/CodeIgniter-Ion-Auth
Ion Auth是一个很有特色的库，它没有过重或不够先进。在大多数情况下，它的功能集将不仅仅满足项目的需求。
优点 轻量级且易于与CodeIgniter集成 支持直接从库发送电子邮件 良好的在线文档和良好的活跃开发者/用户社区 很容易在项目中实现 缺点 比其他一些DB模式更复杂 文档在某些方面缺乏细节
优点 占用空间小(4个文件) 简约，绝对不臃肿 使用phpass进行哈希(优秀) 缺点 只有登录，注销，创建和删除 缺少很多基本特征。阻碍达成协议! 与其说是图书馆，不如说是一个起点
我并不是不尊重上面任何一个库;他们的开发人员所取得的成就以及他们每个人所取得的进步给我留下了深刻的印象，我并不排斥重用他们的一些代码来构建自己的代码。我想说的是，有时在这些项目中，关注点会从基本的“必须拥有”(如硬安全实践)转移到更软的“美好拥有”，这就是我希望补救的地方。
因此:回归基本。
下面是我从身份验证库中最少需要的特性列表。它也恰好是我自己库的功能列表的子集;)
可选测试实现的小足迹 完整的文档 无需自动加载。为提高性能而及时加载库 语言文件支持;没有硬编码的字符串 支持reCAPTCHA，但可选 推荐TRUE随机盐生成(例如使用random.org或random.irb.hr) 可选插件，支持第三方登录(OpenID, Facebook连接，谷歌帐户等) 使用用户名或电子邮件登录 分离用户和配置文件数据 电子邮件激活和丢失密码 自动cookie登录功能 用于哈希的可配置phpass(当然是适当的!) 密码哈希 自体蛋白编码的哈希 对丢失的密码代码进行哈希 连接到CI的验证系统 没有安全问题! 服务器端强制强密码策略，可选的客户端(Javascript)验证器 使用最佳实践对策对字典和DoS攻击强制最大失败的登录尝试次数! 所有数据库访问都是通过准备好的(绑定的)语句完成的!
注意:最后几个点是不超高安全性的过量使用，你的web应用程序不需要它们。如果一个认证库不能100%满足这些安全标准，不要使用它!
最近一些引人注目的不负责任的程序员将它们排除在软件之外的例子:#17是莎拉·佩林的美国在线电子邮件在总统竞选期间被黑客入侵;最近，布兰妮·斯皮尔斯、巴拉克·奥巴马、福克斯新闻等人的推特账户遭到黑客攻击，罪魁祸首就是#18和#19这两个可恶的组合;排在第20位的是中国黑客如何在2008年一次自动黑客攻击中从7万多家韩国网站窃取了900万项个人信息。
这些攻击不是脑部手术。如果你让后门大开，你就不应该把前门栓上，让自己产生一种虚假的安全感。此外，如果你对编码足够认真，选择一个像CodeIgniter这样的最佳实践框架，你至少应该正确地完成最多的基本安全措施。
& lt; rant>
基本上，它是这样的:我也不在乎如果一个认证库提供了一大堆功能，高级角色管理，PHP4兼容性，漂亮的CAPTCHA字体，国家表，完整的管理面板，钟声和口哨——如果库实际上使我的网站更不安全不遵循最佳实践。它是一个身份验证包;它只需要做一件事:身份验证。如果它没有做到那，它实际上弊大于利。
& lt; / rant>
/ Jens罗兰
我是Redux Auth的开发人员，你提到的一些问题已经在版本2 beta中修复了。你也可以从官方网站上下载样例应用程序。
需要自动加载(影响性能) 使用“安全问题”这个固有的不安全概念。阻碍达成协议!
安全问题现在已经不再使用，一个更简单的遗忘密码系统已经到位。
返回类型有点像真、假、错误和成功代码的大杂烩
这在版本2中得到了修复，并返回布尔值。我和你一样讨厌大杂烩。
不会连接到CI的验证系统
示例应用程序使用CI的验证系统。
不允许用户重新发送“丢失密码”代码
进行中的工作
我还实现了一些其他功能，如电子邮件视图，这让你可以选择在你的电子邮件中使用CodeIgniter助手。
这项工作仍在进行中，如果有更多的建议，请继续提出。
爆米花
Ps:谢谢你推荐Redux。
Ion_auth !看起来很有前途，占地面积小!我喜欢. .
http://github.com/benedmunds/CodeIgniter-Ion-Auth
注意，Jens Roland的“综合清单”不包括用户角色。如果你有兴趣分配不同的用户角色(比如管理员/用户或管理员/编辑器/用户)，这些库允许:
Tank_Auth (Jens列表中的第一个)没有用户角色。我知道这不是鉴定的一部分，但既然
如果你需要的话，用一个库来处理这两件事是很有意义的。因此，我将从Tank_Auth切换到Ion_Auth。
Ion_Auth击败tank_auth主要有两个原因，用户角色和文档，这两个在tank_auth中是缺失的。
Tank Auth看起来不错，但是文档只有一页关于如何安装的解释，以及每个PHP文件的快速运行。至少这是我在谷歌上搜了很多之后找到的。也许当人们说Tank Auth是良好记录的时候，他们的意思是代码是良好注释的。这是一件好事，但与文档不同。如果有一些关于如何将Tank Auth的功能与现有代码集成的文档就好了。
我正在尝试Ion_Auth，谢谢它，顺便说一句…
< >强SimpleLoginSecure
我遇到了Flexi Auth (http://haseydesign.com/flexi-auth/)。它看起来很有前途，我已经开始使用它了。它有奇妙的特征。与CI完全集成，并带有两个不同的库文件，其中一个包含所有函数，另一个只包含验证。
其中最好的一点是，新注册的会员可以在指定的时间内暂时访问网站，直到他们点击电子邮件中的链接并激活为止。
