この記事では、Yii フレームワークのログインプロセスを詳細に分析します。参考のためにみんなで共有してください。具体的な分析は次のとおりです:
Yii は、特にセッション、Cookie、ユーザー認証に関して、初心者にとって使い始めるのが少し難しいです。ここで、Yii のログインプロセスと、Yii 開発におけるセッション、Cookie、およびユーザー認証のセットアップ方法に関する一般的な知識について話しましょう
1. 概要
Yii はフルスタック MVC フレームワークです。いわゆるフルスタックとは、MVC、ORM (DAO/ActiveRecord)、グローバリゼーション (I18N/L10N)、キャッシュなど、Web 開発で使用されるすべての機能を Yii フレームワーク自体が実装することを意味します。 、jQuery ベースの AJAX サポート、ロールベースのユーザー検証 (認証およびロールベースのアクセス制御)、プログラム スケルトン ジェネレーター (スキャフォールディング)、入力検証 (入力検証)、フォーム ウィジェット、イベント、テーマ、Web サービス、ログ記録およびその他の機能詳細は公式説明をご覧ください
ここで話したいのは、Yii のログインプロセスです。Yii で開発するには、通常、Yii シェルと呼ばれるコンソールツールを使用してプログラムのスケルトンを生成します。このスケルトンは、Web プログラム開発の基本構造を割り当てます。 Ruby on Rails を知っていれば、原理は同じです
。2. ウェブサイトのログインプロセス
生成されたプログラムには保護されたディレクトリがあり、以下のコントローラーディレクトリに SiteController.php というファイルがあります。このファイルには、デフォルトでプログラムのログインプロセスが最初から開始されます。アドレス http://domain.com/index.php?r=site/login は、ルーターと呼ばれるコンポーネントを通じて前述の actionLogin メソッドに転送されます。このルートの機能は、ここで説明する actionLogin メソッドの焦点ではありません。コードはこんな感じです
最初に LoginForm クラスを初期化し、ユーザーがログインをクリックした後にそれがリクエストであるかどうかを判断します (リクエストに POST データがあるかどうかを確認します)。そうである場合は、まず入力を検証してから ($model->validate) 試してください。ログイン ($model- >logiin) し、成功した場合はログイン前のページにジャンプします。そうでない場合は、ログイン ページが表示されます。
3.フレームワークログインプロセス
LoginForm クラスは CFormModel を継承し、CModel を間接的に継承するため、検証やエラー処理などのいくつかの機能を提供するために CModel を提供します。ログイン メソッドは、最初にユーザーが指定したユーザー名とパスワードを生成します。ユーザー エンティティを表すために使用される UserIdentity クラスは、ユーザー名とパスワードがデータベースから一致するかどうかを判断するなど、実際の検証アクションを実行します。LoginForm クラスの login メソッドは、ログインが成功したかどうかをクエリして判断します。認証にエラーが発生した場合、Yii::app()->user->login メソッドが実行され、ユーザーが実際にシステムにログインできるようになります。上記のプロセスはユーザー プログラムによって提供されます。 、および CWebUser のログイン メソッドである Yii::app()- >user->login は、Yii フレームワークによって提供されるプロセスです。この中のコードを以下に示します。 (Yii)webauthCWebUser.php ファイルにあります。
パラメータ $identity は、上記のログイン時に生成された UserIdentity クラスであり、上記の ID、名前、および場合によってはその他のカスタマイズされたデータなどの基本的なユーザー情報が含まれています。この例では、プログラムはまず $identity のデータを CWebUser にコピーします。 、このプロセスには、対応するセッションの生成が含まれます。実際、主な目的はセッションを生成することです。その後、パラメーター $duration (Cookie が保存される時間) とallowAutoLogin 属性に基づいて、Cookie を生成するかどうかが判断されます。次回からは自動的にログインするために使用できます。その場合、Cookie (saveToCookie) が生成されます。
まず、新しい CHttpCookie を作成します。Cookie のキーは getStateKeyPrefix メソッドを通じて取得されます。このメソッドは md5('Yii.'.get_class($this).'.'.Yii::app()->getId を返します。 ()) デフォルトでは、この Id は crc32 関数によって生成される値ですが、毎回同じ値が生成されます。 Cookie の有効期限を設定し、基本データを含む新しい配列を作成します。次に、より重要なことは、Cookie の値 $app->getSecurityManager()->hashData( Serialize($data))、getSecurityManager は CSecurityManager オブジェクトを返し、hashData メソッドを呼び出します。
if($this->_validation==='SHA1'){
$pack='H40';
$func='sha1';
}
他{
$pack='H32';
$func='md5';
}
$key=$this->getValidationKey();
$key=str_pad($func($key), 64, chr(0));
return $func((str_repeat(chr(0x5C), 64) ^ substr($key, 0, 64)) .pack($pack, $func((str_repeat(chr(0x36), 64) ^ substr($key, 0, 64)) 。 $data)));
}
hashData は computHMAC メソッドを呼び出してハッシュ値を生成します。ハッシュ アルゴリズムには SHA1 と MD5 があり、ハッシュ化の際に validationKey (検証コード) も生成され、その値と比較されます。一部の意図的に配置された操作により、最終的に 40 ビットの SHA1 ハッシュ値が生成されます。hashData メソッドは、最終的に computeHMAC によって生成されたハッシュ値と、シリアル化された元のデータによって生成された文字列を返します。なぜ確認コードが必要なのですか?
まず、Cookie ベースの認証がどのように機能するかを見てみましょう。ユーザーがこの Web サイトにアクセスするたびに、サーバーが Cookie を生成してブラウザーに送信し、有効期限に基づいて一定期間ブラウザーに保存します。ブラウザ経由 Cookie は HTTP リクエストとともに送信されます。これは http プロトコルの一部であり、サーバーは送信された Cookie を判断して、ユーザーがログインしているユーザーと見なせるかどうかを判断します。ただし、Cookie はクライアントが閲覧するために使用され、サーバーや他のプログラムによっても送信されるため、送信された Cookie が偽のもので改ざんされている可能性があるため、サーバーはそれが Cookie であるかどうかを判断するために何らかの検証メカニズムを使用する必要があります。この検証メカニズムは、Cookie 内にあります。これには、ハッシュ値と、このハッシュ値の文字列を生成した元のデータが含まれています。Cookie を受信した後、サーバーは元のデータを取り出し、それに基づいてハッシュ値を生成します。送信されたハッシュ値と比較する元のメソッドが同じである場合、その Cookie は信頼されます。たとえば、私の Yii ウェブサイトは次のような Cookie を生成しました。
クッキー名:b72e8610f8decd39683f245d41394b56クッキー値: 1cbb64bdea3e92c4ab5d5cb16a67637158563114a%3A4%3A%7Bi%3A0%3Bs%3A7%3A%22maxwell%22%3Bi%3A1%3Bs%3A7%3A%22maxwell%22%3Bi%3A2%3Bi%3 3Bi%3A3 % 3Ba%3A2%3A%7Bs%3A8%3A%22realname%22%3Bs%3A6%3A%22helloc%22%3Bs%3A4%3A%22myId%22%3Bi%3A123%3B%7D%7D
Cookie 名は Web サイトによって均一に生成される md5 値であり、Cookie 値の値は 2 つの部分で構成され、最初の部分は hashData メソッドによって生成された文字列であり、2 番目の部分は元の値です。つまり、前の 1cbb64bdea3e92c4ab5d5cb16a67637158563114 がハッシュ値であり、その後に元の値が続きます。このハッシュ値は、SHA1 を使用して生成された 40 ビット文字列であり、サーバーはアルゴリズムの背後で元の値を値にハッシュし、渡されたハッシュ値と比較します。それが合法であり、違法なリクエストを審査しないことを知るには、確認コードについてはどうですか?
サーバーが単純に元の値を SHA1 または MD5 で直接ハッシュする場合、リクエストを送信した人はサーバーの検証を通過するために元の値とハッシュ値を自由に変更できます。SHA1 アルゴリズムは公開されているため、誰でも使用できます。したがって、サーバーは、クライアントが元の値から正しいハッシュを取得できないハッシュ値を生成するときに、クライアントが知らない検証コードを追加する必要があります (少し複雑です:)。そして、この検証コードはサイト全体に共通である必要があるため、上記の getValidationKey メソッドはサイト全体に固有の検証コードを生成し、デフォルトでは検証コードは (yii) に保存されます。 runtimestate.bin ファイル 中。これはすべてのリクエストで同じになります。
ログインプロセスの最後に、生成された Cookie がブラウザに送信されます。これは、次回リクエストするときに検証に使用できます。
この記事が、Yii フレームワークに基づいた PHP プログラムの設計に役立つことを願っています。
http://www.bkjia.com/PHPjc/920980.html