我是Redux Auth的开发人员，你提到的一些问题已经在版本2 beta中修复了。你也可以从官方网站上下载样例应用程序。

需要自动加载(影响性能) 使用“安全问题”这个固有的不安全概念。阻碍达成协议!

安全问题现在已经不再使用，一个更简单的遗忘密码系统已经到位。

返回类型有点像真、假、错误和成功代码的大杂烩

这在版本2中得到了修复，并返回布尔值。我和你一样讨厌大杂烩。

不会连接到CI的验证系统

示例应用程序使用CI的验证系统。

不允许用户重新发送“丢失密码”代码

进行中的工作

我还实现了一些其他功能，如电子邮件视图，这让你可以选择在你的电子邮件中使用CodeIgniter助手。

这项工作仍在进行中，如果有更多的建议，请继续提出。

爆米花

Ps:谢谢你推荐Redux。

我使用DX Auth的定制版本。我发现它使用简单，非常容易修改，它有一个用户指南(有很好的例子)，非常类似于Code Igniter的。

更新(2010年5月14日):

事实证明，俄罗斯开发人员Ilya Konyukhov在阅读这篇文章后接受了挑战，并根据下面的建议和要求，为基于DX auth的CI创建了一个新的认证库。

由此产生的坦克认证看起来像OP的问题的答案。在这里，我将大胆地将Tank Auth称为目前CodeIgniter可用的最佳身份验证库。这是一个坚如磐石的库，拥有所有你需要的功能，没有你不需要的臃肿:

坦克身份验证

Pros Full featured Lean footprint (20 files) considering the feature set Very good documentation Simple and elegant database design (just 4 DB tables) Most features are optional and easily configured Language file support reCAPTCHA supported Hooks into CI's validation system Activation emails Login with email, username or both (configurable) Unactivated accounts auto-expire Simple yet effective error handling Uses phpass for hashing (and also hashes autologin codes in the DB) Does not use security questions Separation of user and profile data is very nice Very reasonable security model around failed login attempts (good protection against bots and DoS attacks) (Minor) Cons Lost password codes are not hashed in DB Includes a native (poor) CAPTCHA, which is nice for those who don't want to depend on the (Google-owned) reCAPTCHA service, but it really isn't secure enough Very sparse online documentation (minor issue here, since the code is nicely documented and intuitive)

下载坦克认证在这里

---

最初的回答:

我也实现了我自己的(目前在几周的工作后完成了80%)。我先试了所有其他的;FreakAuth Light, DX Auth, Redux, SimpleLogin, SimpleLoginSecure, pc_user, Fresh Powered，等等。在我看来，它们没有一个达到标准，要么缺乏基本功能，本质上不安全，要么对我的口味来说太臃肿了。

实际上，我在测试CodeIgniter的所有身份验证库时(就在新年之后)对它们进行了详细的汇总。FWIW，我将与你分享:

DX身份验证

Pros Very full featured Medium footprint (25+ files), but manages to feel quite slim Excellent documentation, although some is in slightly broken English Language file support reCAPTCHA supported Hooks into CI's validation system Activation emails Unactivated accounts auto-expire Suggests grc.com for salts (not bad for a PRNG) Banning with stored 'reason' strings Simple yet effective error handling Cons Only lets users 'reset' a lost password (rather than letting them pick a new one upon reactivation) Homebrew pseudo-event model - good intention, but misses the mark Two password fields in the user table, bad style Uses two separate user tables (one for 'temp' users - ambiguous and redundant) Uses potentially unsafe md5 hashing Failed login attempts only stored by IP, not by username - unsafe! Autologin key not hashed in the database - practically as unsafe as storing passwords in cleartext! Role system is a complete mess: is_admin function with hard-coded role names, is_role a complete mess, check_uri_permissions is a mess, the whole permissions table is a bad idea (a URI can change and render pages unprotected; permissions should always be stored exactly where the sensitive logic is). Dealbreaker! Includes a native (poor) CAPTCHA reCAPTCHA function interface is messy

FreakAuth光

Pros Very full featured Mostly quite well documented code Separation of user and profile data is a nice touch Hooks into CI's validation system Activation emails Language file support Actively developed Cons Feels a bit bloated (50+ files) And yet it lacks automatic cookie login (!) Doesn't support logins with both username and email Seems to have issues with UTF-8 characters Requires a lot of autoloading (impeding performance) Badly micromanaged config file Terrible View-Controller separation, with lots of program logic in views and output hard-coded into controllers. Dealbreaker! Poor HTML code in the included views Includes substandard CAPTCHA Commented debug echoes everywhere Forces a specific folder structure Forces a specific Ajax library (can be switched, but shouldn't be there in the first place) No max limit on login attempts - VERY unsafe! Dealbreaker! Hijacks form validation Uses potentially unsafe md5 hashing

pc_user

优点 它占地面积小，功能设置不错 轻量级，无膨胀(3个文件) 优雅的自动cookie登录 附带可选的测试实现(不错的操作) 缺点 使用旧的CI数据库语法(不太安全) 不会连接到CI的验证系统 有点不直观的状态(角色)系统(索引颠倒-不切实际) 使用可能不安全的sha1哈希

新鲜的动力

优点 占用空间小(6个文件) 缺点 缺少很多基本特征。阻碍达成协议! 一切都是硬编码的。阻碍达成协议!

Redux / Ion认证

根据CodeIgniter wiki, Redux已经停产，但Ion Auth分支正在蓬勃发展:https://github.com/benedmunds/CodeIgniter-Ion-Auth

Ion Auth是一个很有特色的库，它没有过重或不够先进。在大多数情况下，它的功能集将不仅仅满足项目的需求。

优点 轻量级且易于与CodeIgniter集成 支持直接从库发送电子邮件 良好的在线文档和良好的活跃开发者/用户社区 很容易在项目中实现 缺点 比其他一些DB模式更复杂 文档在某些方面缺乏细节

简单登录安全

优点 占用空间小(4个文件) 简约，绝对不臃肿 使用phpass进行哈希(优秀) 缺点 只有登录，注销，创建和删除 缺少很多基本特征。阻碍达成协议! 与其说是图书馆，不如说是一个起点

---

不要误解我的意思:我并不是不尊重上述任何一个库;他们的开发人员所取得的成就以及他们每个人所取得的进步给我留下了深刻的印象，我并不排斥重用他们的一些代码来构建自己的代码。我想说的是，有时在这些项目中，关注点会从基本的“必须拥有”(如硬安全实践)转移到更软的“美好拥有”，这就是我希望补救的地方。

因此:回归基本。

CodeIgniter的身份验证完成正确

下面是我从身份验证库中最少需要的特性列表。它也恰好是我自己库的功能列表的子集;)

Tiny footprint with optional test implementation Full documentation No autoloading required. Just-in-time loading of libraries for performance Language file support; no hard-coded strings reCAPTCHA supported but optional Recommended TRUE random salt generation (e.g. using random.org or random.irb.hr) Optional add-ons to support 3rd party login (OpenID, Facebook Connect, Google Account, etc.) Login using either username or email Separation of user and profile data Emails for activation and lost passwords Automatic cookie login feature Configurable phpass for hashing (properly salted of course!) Hashing of passwords Hashing of autologin codes Hashing of lost password codes Hooks into CI's validation system NO security questions! Enforced strong password policy server-side, with optional client-side (Javascript) validator Enforced maximum number of failed login attempts with BEST PRACTICES countermeasures against both dictionary and DoS attacks! All database access done through prepared (bound) statements!

注意:最后这几点并不是超高安全性，你的web应用程序不需要它们。如果一个认证库不能100%满足这些安全标准，不要使用它!

最近一些引人注目的不负责任的程序员将它们排除在软件之外的例子:#17是莎拉·佩林的美国在线电子邮件在总统竞选期间被黑客入侵;最近，布兰妮·斯皮尔斯、巴拉克·奥巴马、福克斯新闻等人的推特账户遭到黑客攻击，罪魁祸首就是#18和#19这两个可恶的组合;排在第20位的是中国黑客如何在2008年一次自动黑客攻击中从7万多家韩国网站窃取了900万项个人信息。

这些攻击不是脑部手术。如果你让后门大开，你就不应该把前门栓上，让自己产生一种虚假的安全感。此外，如果您对编码足够认真，可以选择CodeIgniter这样的最佳实践框架，那么您至少应该正确执行最基本的安全措施。

---

<咆哮>

基本上，它是这样的:我不在乎一个认证库是否提供了一堆功能，高级角色管理，PHP4兼容性，漂亮的CAPTCHA字体，国家表，完整的管理面板，花哨的功能——如果这个库没有遵循最佳实践，实际上使我的网站不那么安全。这是一个认证包;它只需要做一件事:身份验证。如果它不能做到这一点，实际上弊大于利。

< /咆哮>

/延斯·罗兰

Tank Auth看起来不错，但是文档只有一页关于如何安装的解释，以及每个PHP文件的快速运行。至少这是我在谷歌上搜了很多之后找到的。也许当人们说Tank Auth是良好记录的时候，他们的意思是代码是良好注释的。这是一件好事，但与文档不同。如果有一些关于如何将Tank Auth的功能与现有代码集成的文档就好了。

Ion_Auth击败tank_auth主要有两个原因，用户角色和文档，这两个在tank_auth中是缺失的。

注意，Jens Roland的“综合清单”不包括用户角色。如果你有兴趣分配不同的用户角色(比如管理员/用户或管理员/编辑器/用户)，这些库允许:

Ion_Auth (Redux的重写) 回来的 后端支持

Tank_Auth (Jens列表中的第一个)没有用户角色。我知道这不是鉴定的一部分，但既然

身份验证和角色管理都是在页面加载时处理的 两者都涉及安全 相同的表/模型可用于两者。 两者都可以设置为在控制器构造函数中加载(甚至是自动加载)

如果你需要的话，用一个库来处理这两件事是很有意义的。因此，我将从Tank_Auth切换到Ion_Auth。