いくつかあります。どれが維持され、使いやすいですか？それらの長所と短所は何ですか?
153331 次
11 に答える
466
更新 (2010 年 5 月 14 日):
ロシアの開発者 Ilya Konyukhov は、これを読んだ後、以下の推奨事項と要件に従って、DX Auth に基づいて CI 用の新しい認証ライブラリを作成した後、難題を解決しました。
結果として得られるTank Authは、OP の質問に対する答えのように見えます。ここでは、Tank Auth を、現在入手可能な CodeIgniter の最高の認証ライブラリと呼ぶことにします。これは、必要なすべての機能を備え、不要な肥大化がない堅牢なライブラリです。
タンク認証
長所
- フル機能
- 機能セットを考慮したリーン フットプリント (20 ファイル)
- 非常に優れたドキュメント
- シンプルで洗練されたデータベース設計 (わずか 4 つの DB テーブル)
- ほとんどの機能はオプションであり、簡単に構成できます
- 言語ファイルのサポート
- reCAPTCHA 対応
- CI の検証システムへのフック
- 有効化メール
- 電子メール、ユーザー名、またはその両方でログイン (構成可能)
- アクティブ化されていないアカウントは自動期限切れになります
- シンプルで効果的なエラー処理
- ハッシュにphpassを使用します（また、DBの自動ログインコードをハッシュします）
- セキュリティの質問を使用しない
- ユーザー データとプロファイル データの分離は非常に優れています
- 失敗したログイン試行に関する非常に合理的なセキュリティ モデル (ボットや DoS 攻撃に対する優れた保護)
(マイナー) 短所
- 失われたパスワード コードは DB でハッシュされません
- (Google が所有する) reCAPTCHA サービスに依存したくない人にとっては便利ですが、実際には十分に安全ではありません。
- 非常にまばらなオンライン ドキュメント (コードは適切にドキュメント化されており、直感的であるため、ここでは軽微な問題です)
元の答え:
私自身も実装しました (現在、数週間の作業で約 80% が完了しています)。最初に他のすべてを試しました。FreakAuth Light、DX Auth、Redux、SimpleLogin、SimpleLoginSecure、pc_user、Fresh Powered など。基本的な機能が不足しているか、本質的に安全でないか、または私の好みに対して肥大化しすぎているかのいずれかで、IMO に匹敵するものはありませんでした。
実際、CodeIgniter のすべての認証ライブラリをテストしていたとき (新年の直後) に、その詳細なまとめを行いました。FWIW、私はあなたとそれを共有します：
DX認証
長所
- 非常にフル機能
- 中程度のフットプリント (25 個以上のファイル) ですが、かなりスリムに感じます
- 優れたドキュメンテーション。ただし、英語が少し壊れているものもあります
- 言語ファイルのサポート
- reCAPTCHA 対応
- CI の検証システムへのフック
- 有効化メール
- アクティブ化されていないアカウントは自動期限切れになります
- ソルトには grc.com を提案します (PRNG には悪くありません)
- 保存された「理由」文字列による禁止
- シンプルで効果的なエラー処理
短所
- ユーザーが紛失したパスワードを「リセット」できるようにするだけです (再アクティブ化時に新しいパスワードを選択させるのではなく)
- Homebrew 疑似イベント モデル - 善意ですが、的外れです
- user テーブルの 2 つのパスワード フィールド、不適切なスタイル
- 2 つの個別のユーザー テーブルを使用します (1 つは「一時」ユーザー用 - あいまいで冗長)
- 安全でない可能性のある md5 ハッシュを使用します
- 失敗したログイン試行は、ユーザー名ではなく IP によってのみ保存されます - 安全ではありません!
- データベースでハッシュ化されていない自動ログインキー - パスワードをクリアテキストで保存するのと同じくらい安全ではありません!
- ロール システムは完全に混乱しています。ハードコードされたロール名を持つ is_admin 関数、is_role が完全に混乱、check_uri_permissions が混乱、パーミッション テーブル全体が悪い考えです (URI が変更され、ページが保護されずにレンダリングされる可能性があります。パーミッションは常に正確に保存する必要があります)センシティブなロジックがある場所)。合意を壊すもの！
- ネイティブの (貧弱な) CAPTCHA が含まれています
- reCAPTCHA関数のインターフェースが乱雑
フリークオースライト
長所
- 非常にフル機能
- ほとんどの場合、非常によく文書化されたコード
- ユーザー データとプロファイル データの分離はいい感じです
- CI の検証システムへのフック
- 有効化メール
- 言語ファイルのサポート
- 積極的に開発
短所
- 少し肥大化しています（50以上のファイル）
- それでも、自動Cookieログインがありません（！）
- ユーザー名と電子メールの両方を使用したログインはサポートされていません
- UTF-8 文字に問題があるようです
- 多くのオートローディングが必要 (パフォーマンスの妨げ)
- 不適切にマイクロ管理された構成ファイル
- ビューとコントローラにハードコードされた出力の多くのプログラム ロジックによる、ひどいビュー コントローラの分離。合意を壊すもの！
- 含まれているビューの不適切な HTML コード
- 標準以下のCAPTCHAが含まれています
- コメント付きのデバッグがどこにでもエコー
- 特定のフォルダ構造を強制します
- 特定の Ajax ライブラリを強制します (切り替えることはできますが、そもそもそこにあるべきではありません)。
- ログイン試行回数に上限はありません - 非常に安全ではありません! 合意を壊すもの！
- ハイジャックフォームの検証
- 安全でない可能性のある md5 ハッシュを使用します
pc_user
長所
- 小さなフットプリントのための優れた機能セット
- 軽量で肥大化なし (3 ファイル)
- エレガントな自動 Cookie ログイン
- オプションのテスト実装が付属 (いい感じ)
短所
- 古い CI データベース構文を使用する (安全性が低い)
- CI の検証システムにフックしない
- ちょっと非直感的なステータス (ロール) システム (インデックスが逆さま - 非現実的)
- 安全でない可能性のある sha1 ハッシュを使用します
フレッシュパワード
長所
- 小さなフットプリント (6 ファイル)
短所
- 多くの重要な機能が欠けています。合意を壊すもの！
- すべてがハードコードされています。合意を壊すもの！
Redux / イオン認証
CodeIgniter wikiによると、Redux は廃止されましたが、Ion Auth フォークは強化されています: https://github.com/benedmunds/CodeIgniter-Ion-Auth
Ion Auth は、過度に重くも高度でもなく、優れた機能を備えたライブラリです。ほとんどの場合、その機能セットはプロジェクトの要件を満たす以上のものです。
長所
- 軽量で CodeIgniter との統合が簡単
- ライブラリからの直接メール送信をサポート
- 十分に文書化されたオンラインおよび活発な開発者/ユーザー コミュニティ
- プロジェクトへの実装が簡単
短所
- 他のいくつかよりも複雑な DB スキーマ
- ドキュメントには、一部の領域で詳細が欠けています
シンプルログインセキュア
長所
- 小さなフットプリント (4 ファイル)
- ミニマル、絶対に肥大化しない
- ハッシュに phpass を使用 (優れている)
短所
- ログイン、ログアウト、作成、削除のみ
- 多くの重要な機能が欠けています。合意を壊すもの！
- 図書館というより出発点
誤解しないでください:上記のライブラリを軽視するつもりはありません。私は彼らの開発者が達成したことと、それぞれの開発者がどこまで到達したかについて非常に感銘を受けており、自分のコードを構築するために彼らのコードの一部を再利用することを惜しみません。私が言いたいのは、これらのプロジェクトでは、本質的な「必要なもの」(厳格なセキュリティ慣行など) からよりソフトな「あると便利なもの」に焦点が移ることがあるということです。 .
したがって、基本に戻ります。
CodeIgniter の認証が正しく行われました
これは、認証ライブラリからの機能の最小限の必須リストです。また、私自身のライブラリの機能リストのサブセットでもあります;)
- オプションのテスト実装を備えた小さなフットプリント
- 完全なドキュメント
- 自動ロードは必要ありません。パフォーマンスのためのライブラリのジャストインタイム読み込み
- 言語ファイルのサポート; ハードコードされた文字列なし
- reCAPTCHA はサポートされていますが、オプションです
- 推奨される真のランダム ソルト生成 (たとえば、random.org または random.irb.hr を使用)
- サードパーティのログインをサポートするオプションのアドオン (OpenID、Facebook Connect、Google アカウントなど)
- ユーザー名または電子メールを使用してログイン
- ユーザー データとプロファイル データの分離
- アクティベーションおよび紛失したパスワードに関する電子メール
- 自動クッキーログイン機能
- ハッシュ用の構成可能な phpass (もちろん適切にソルト化されています!)
- パスワードのハッシュ
- 自動ログインコードのハッシュ
- 紛失したパスワード コードのハッシュ
- CI の検証システムへのフック
- セキュリティの質問はありません!
- オプションのクライアント側 (Javascript) バリデーターを使用して、サーバー側で強力なパスワード ポリシーを適用
- 辞書攻撃と DoS 攻撃の両方に対するBEST PRACTICES 対策により、失敗したログイン試行の最大回数を強制しました!
- 準備された (バインドされた) ステートメントを介して行われるすべてのデータベース アクセス!
注: これらの最後のいくつかのポイントは、Web アプリケーションに必要のない超高セキュリティのやり過ぎではありません。認証ライブラリがこれらのセキュリティ基準を 100% 満たしていない場合は、使用しないでください。
ソフトウェアから除外した無責任なコーダーの最近の有名な例: #17 は、大統領選挙中にサラ・ペイリンの AOL メールがハッキングされた方法です。最近、ブリトニー・スピアーズ、バラク・オバマ、フォックス・ニュースなどの Twitter アカウントがハッキングされたとき、#18 と #19 の厄介な組み合わせが犯人でした。そして #20 だけでも、中国のハッカーが 2008 年に 1 回の自動ハッキングで 70,000 以上の韓国の Web サイトから 900 万項目の個人情報を盗むことに成功した方法です。
これらの攻撃は脳手術ではありません。バックドアを大きく開けたままにしておく場合、フロントをボルトで固定して誤った安心感に惑わされてはいけません。さらに、CodeIgniter のようなベスト プラクティス フレームワークを選択するほどコーディングに真剣に取り組んでいる場合は、少なくとも最も基本的なセキュリティ対策を適切に行う必要があります。
<暴言>
基本的には、次のようになります。認証ライブラリが一連の機能、高度なロール管理、PHP4 互換性、きれいな CAPTCHA フォント、国別テーブル、完全な管理パネル、さまざまな機能を提供するかどうかは気にしません。ベスト プラクティスに従わなかったため、サイトの安全性が低下しました。これは認証パッケージです。1 つのことを正しく行う必要があります: 認証です。それができない場合、実際には良いことよりも害を及ぼしています。
</rant>
/イェンス・ローランド
于 2009-01-24T23:49:13.303 に答える
57
Jens Rolandによる「包括的なリスト」には、ユーザーの役割は含まれていないことに注意してください。さまざまなユーザーロール（admin/userやadmin/editor / userなど）の割り当てに関心がある場合は、次のライブラリで次のことが可能になります。
- Ion_Auth（Reduxの書き換え）
- 戻ってきた
- バックエンドプロ
Tank_Auth（上記のJensのリストの＃1）にはユーザーロールがありません。私はそれが認証の一部ではないことを理解していますが、
- 認証とロール管理は両方ともページの読み込み時に処理されます
- どちらもセキュリティを必要とします
- 同じテーブル/モデルを両方に使用できます。
- 両方とも、コントローラーコンストラクターにロードするように設定できます（または自動ロードすることもできます）
必要に応じて、両方を処理する1つのライブラリを用意することは非常に理にかなっています。このため、Tank_AuthからIon_Authに切り替えています。
于 2010-07-09T13:42:16.050 に答える
37
Ion_auth! 非常に有望で小さな設置面積に見えます！好き..
于 2010-03-10T20:09:35.233 に答える
30
私は Redux Auth の開発者です。あなたが言及した問題のいくつかは、バージョン 2 ベータ版で修正されています。これは、サンプル アプリケーションと一緒に公式 Web サイトからダウンロードすることもできます。
- オートローディングが必要 (パフォーマンスの妨げ)
- 「セキュリティの質問」という本質的に危険な概念を使用します。合意を壊すもの！
セキュリティの質問は現在使用されておらず、より簡単な忘れられたパスワード システムが導入されています。
- 戻り値の型は、true、false、エラー、および成功コードのごちゃまぜです
これはバージョン 2 で修正され、ブール値を返します。私はあなたと同じくらい寄せ集めが嫌いでした。
- CI の検証システムにフックしない
サンプル アプリケーションは、CI の検証システムを使用します。
- ユーザーが「失われたパスワード」コードを再送信することを許可しない
進行中の作業
メール ビューなどの他の機能も実装しました。これにより、メールで CodeIgniter ヘルパーを使用できるようになります。
これはまだ進行中の作業ですので、他に提案があれば、引き続きお寄せください。
-ポップコーン
Ps : Redux を推薦していただきありがとうございます。
于 2009-01-28T15:46:54.327 に答える
14
Flexi Auth ( http://haseydesign.com/flexi-auth/ ) に出会いました。とても有望そうで、私はそれを使い始めました。素晴らしい機能があります。CI と完全に統合されており、2 つの異なるライブラリ ファイルが付属しています。1 つはすべての機能が非常に重くロードされており、もう 1 つは検証のみが含まれています。
最良の方法の 1 つは、新しく登録したメンバーが、電子メールのリンクをクリックしてアクティブ化するまで、一定期間、サイトに一時的にアクセスできることです。
于 2013-10-30T20:08:46.907 に答える
8
Ion_Auth は、主にユーザーの役割とドキュメントの 2 つの理由で tank_auth に勝っています。これら 2 つは tank_auth にはありません。
于 2010-10-27T08:25:38.357 に答える
6
DX Authのカスタマイズされたバージョンを使用します。使い方は簡単で、変更も非常に簡単で、Code Igniter と非常によく似たユーザー ガイド (優れた例を含む)があります。
于 2008-12-10T18:08:31.020 に答える
4
BackendPro もご覧ください。
最終的には、おそらく独自のものを作成することになるでしょうが、DX Auth、Freak Auth、BackendPro などから概念を借用することには何の問題もありません。
パッケージ化されたアプリに関する私の経験では、それらは特定の構造に固有のものであり、ハックを必要とせずにそれらを自分のアプリケーションに統合するのに問題がありました。プレパッケージに更新がある場合は、それらを移行する必要があります.
また、CI コードで Smarty と ADOdb を使用しているため、何があってもコードを大幅に変更することになります。
于 2008-12-13T02:53:36.020 に答える
3
私は Ion_Auth を試していますが、感謝しています...
SimpleLoginSecure 認証をシンプルかつ安全にします。
于 2011-02-26T16:13:47.070 に答える
3
Tank Auth は良さそうに見えますが、ドキュメントはインストール方法の 1 ページの説明と、各 PHP ファイルの簡単な概要のみです。少なくとも、たくさんのグーグル検索の後に見つけたのはそれだけです。Tank Auth が十分に文書化されているという上記の人々の意味は、コードが十分にコメントされているということかもしれません。それは良いことですが、ドキュメントとは異なります。Tank Auth の機能を既存のコードに統合する方法についてのドキュメントがあると便利です。
于 2010-11-21T04:23:33.900 に答える