PHP Authのダウンロード - PHP Authソースコードのダウンロード

認証

PHPの認証。シンプル、軽量、そして安全。

一度作成すれば、どこでも使用できます。

フレームワークやデータベースに完全に依存しません。

なぜこれが必要なのでしょうか?

認証システムが弱い Web サイトはたくさんあります。そのようなサイトを構築しないでください。
すべての PHP プロジェクトに新しい認証システムを再実装するのは得策ではありません。
独自の認証クラスを少しずつ構築し、それをすべてのプロジェクトにコピーすることもお勧めできません。
使いやすい API を備えた安全な認証システムは、徹底的に設計および計画する必要があります。
重要なインフラストラクチャに対するピアレビューは必須です。

要件

PHP 5.6.0以降
- PDO (PHP データオブジェクト) 拡張機能 ( pdo )
  - MySQL ネイティブドライバー ( mysqlnd )またはPostgreSQL ドライバー ( pgsql )またはSQLite ドライバー ( sqlite )
- OpenSSL 拡張機能 ( openssl )
MySQL 5.5.3以降、 MariaDB 5.5.23以降、 PostgreSQL 9.5.10以降、 SQLite 3.14.1 以降、またはその他の SQL データベース

インストール

Composer [?] を介してライブラリをインクルードします。
```
 $ composer require delight-im/auth
```

Composer オートローダーを含めます。

 require __DIR__ . ' /vendor/autoload.php ' ;

データベースをセットアップし、必要なテーブルを作成します。
- マリアDB
- MySQL
- PostgreSQL
- SQLite

アップグレード中

このプロジェクトの以前のバージョンから移行しますか?ヘルプについては、アップグレードガイドを参照してください。

使用法

新しいインスタンスの作成
登録（サインアップ）
ログイン（サインイン）
メール認証
ユーザーのログイン状態を維持する
パスワードのリセット（「パスワードを忘れた場合」）
- リクエストの開始
- 試行の検証
- パスワードを更新する
現在のユーザーのパスワードを変更する
現在のユーザーのメールアドレスを変更する
確認リクエストの再送信
ログアウト
ユーザー情報へのアクセス
- ログイン状態
- ユーザーID
- 電子メールアドレス
- 表示名
- ステータス情報
- ユーザーが「記憶」されているかどうかを確認する
- IPアドレス
- 追加のユーザー情報
ユーザーのパスワードを再確認する
役割（またはグループ）
- 役割の確認
- 利用可能な役割
- 権限（またはアクセス権、特権、または機能）
- カスタムロール名
パスワードのリセットの有効化または無効化
スロットリングまたはレート制限
管理 (ユーザーの管理)
- 新しいユーザーの作成
- ユーザーの削除
- ユーザーへの役割の割り当て
- ユーザーから役割を奪う
- 役割の確認
- ユーザーの偽装 (ユーザーとしてログイン)
- ユーザーのパスワードを変更する
クッキー
- ライブラリの Cookie の名前を変更する
- Cookie のドメインスコープの定義
- Cookie が使用できるパスを制限する
- クライアント側スクリプトによる Cookie へのアクセスの制御
- Cookie のトランスポートセキュリティの構成
公共事業
- ランダムな文字列を作成する
- RFC 4122 に従って UUID v4 を作成する
セッションデータの読み取りと書き込み

新しいインスタンスの作成

 // $ db = new  PDO ( ' mysql:dbname=my-database ; host = localhost ; charset = utf8mb4' , ' my-username' , ' my-password' ) ;
// or
// $ db = new  PDO ( ' pgsql:dbname=my-database ; host = localhost ; port = 5432 ' , ' my-username' , ' my-password' ) ;
// or
// $ db = new  PDO ( ' sqlite:../Databases/my-database.sqlite' ) ;

// or

// $ db =  Delight D b P doDatabase::fromDsn ( new  Delight D b P doDsn ( ' mysql:dbname=my-database ; host = localhost ; charset = utf8mb4' , ' my-username' , ' my-password' ) ) ;
// or
// $ db =  Delight D b P doDatabase::fromDsn ( new  Delight D b P doDsn ( ' pgsql:dbname=my-database ; host = localhost ; port = 5432 ' , ' my-username' , ' my-password' ) ) ;
// or
// $ db =  Delight D b P doDatabase::fromDsn ( new  Delight D b P doDsn ( ' sqlite:../Databases/my-database.sqlite' ) ) ;

$ auth = new  Delight  Auth  Auth ( $ db );

すでに開いているPDO接続がある場合は、それを再利用してください。データベースユーザー (例: my-username ) には、このライブラリ (またはその親データベース) で使用されるテーブルに対する少なくともSELECT 、 INSERT 、 UPDATE 、およびDELETE権限が必要です。

Web サーバーがプロキシサーバーの背後にあり、 $_SERVER['REMOTE_ADDR']プロキシの IP アドレスのみが含まれている場合は、ユーザーの実際の IP アドレスを$ipAddressという名前の 2 番目の引数のコンストラクターに渡す必要があります。デフォルトは、PHP が受け取る通常のリモート IP アドレスです。

このライブラリのデータベーステーブルに共通のプレフィックス (たとえば、 usersの代わりにmy_users ) が必要な場合 (他のテーブルも同様)、そのプレフィックス (例: my_ ) を$dbTablePrefixという名前のコンストラクターの 3 番目のパラメーターとして渡します。これはオプションであり、デフォルトではプレフィックスは空です。

開発中、このライブラリによって実行されるリクエストの制限またはスロットリングを無効にすることが必要な場合があります。これを行うには、 $throttlingという名前のコンストラクターに 4 番目の引数としてfalseを渡します。この機能はデフォルトで有効になっています。

セッションの存続期間中、一部のユーザーデータは、別のセッションのクライアントまたは管理者によってリモートで変更される可能性があります。つまり、この情報はデータベース内の信頼できるソースと定期的に再同期する必要があり、このライブラリは自動的に再同期します。デフォルトでは、これは 5 分ごとに発生します。この間隔を変更する場合は、 $sessionResyncIntervalという名前のカスタム間隔を秒単位でコンストラクターに 5 番目の引数として渡します。

すべてのデータベーステーブルに共通のデータベース名、スキーマ名、または明示的に指定する必要があるその他の修飾子が必要な場合は、オプションでその修飾子を$dbSchemaという名前の 6 番目のパラメーターとしてコンストラクターに渡すことができます。

PdoDatabaseインスタンス (例: $db ) を独立して使用したい場合は、データベースライブラリのドキュメントを参照してください。

登録（サインアップ）

 try {
    $ userId = $ auth -> register ( $ _POST [ ' email ' ], $ _POST [ ' password ' ], $ _POST [ ' username ' ], function ( $ selector , $ token ) {
        echo ' Send ' . $ selector . ' and ' . $ token . ' to the user (e.g. via email) ' ;
        echo '  For emails, consider using the mail(...) function, Symfony Mailer, Swiftmailer, PHPMailer, etc. ' ;
        echo '  For SMS, consider using a third-party service and a compatible SDK ' ;
    });

    echo ' We have signed up a new user with the ID ' . $ userId ;
}
catch (  Delight  Auth  InvalidEmailException $ e ) {
    die ( ' Invalid email address ' );
}
catch (  Delight  Auth  InvalidPasswordException $ e ) {
    die ( ' Invalid password ' );
}
catch (  Delight  Auth  UserAlreadyExistsException $ e ) {
    die ( ' User already exists ' );
}
catch (  Delight  Auth  TooManyRequestsException $ e ) {
    die ( ' Too many requests ' );
}

注:匿名コールバック関数はクロージャです。したがって、独自のパラメータのほかに、内部で使用できるのは$_GET 、 $_POST 、 $_COOKIE 、 $_SERVERなどのスーパーグローバルだけです。親スコープの他の変数については、パラメーターリストの後にuse句を追加して、内部で使用可能なコピーを明示的に作成する必要があります。

3 番目のパラメータのユーザー名はオプションです。ユーザー名を管理したくない場合は、そこにnullを渡すことができます。

一方、一意のユーザー名を強制したい場合は、 register代わりにregisterWithUniqueUsernameを呼び出すだけで、 DuplicateUsernameExceptionをキャッチできるように準備してください。

注:ユーザー名を受け入れて管理する場合、文字クラス[x00-x1fx7f/:\]のような非印刷制御文字や特定の印刷可能な特殊文字を除外することができます。これを行うには、 Auth#registerまたはAuth#registerWithUniqueUsernameへの呼び出しを条件分岐内でラップします。たとえば、次の条件が満たされる場合にのみユーザー名を受け入れることができます。

 if ( preg_match ( ' /[x00-x1fx7f/: \\ ]/ ' , $ username ) === 0 ) {
    // ...
}

電子メール検証の場合、セレクターとトークンを使用して URL を構築し、それをユーザーに送信する必要があります。例:

 $ url = ' https://www.example.com/verify_email?selector= ' . urlencode ( $ selector ) . ' &token= ' . urlencode ( $ token );

電子メール検証を実行したくない場合は、 Auth#registerの最後のパラメータ、つまり匿名関数またはクロージャを省略します。新しいユーザーはすぐにアクティブになります。

追加のユーザー情報を保存する必要がありますか?ここを読んでください。

注:ユーザーに電子メールを送信するときは、この時点では (オプションの) ユーザー名が (新しい) 電子メールアドレスの所有者に受け入れられるかどうかまだ確認されていないことに注意してください。実際のアドレスの所有者ではない人によって選択された攻撃的または誤解を招く言葉が含まれている可能性があります。

ログイン（サインイン）

 try {
    $ auth -> login ( $ _POST [ ' email ' ], $ _POST [ ' password ' ]);

    echo ' User is logged in ' ;
}
catch (  Delight  Auth  InvalidEmailException $ e ) {
    die ( ' Wrong email address ' );
}
catch (  Delight  Auth  InvalidPasswordException $ e ) {
    die ( ' Wrong password ' );
}
catch (  Delight  Auth  EmailNotVerifiedException $ e ) {
    die ( ' Email not verified ' );
}
catch (  Delight  Auth  TooManyRequestsException $ e ) {
    die ( ' Too many requests ' );
}

一方、電子メールアドレスによるログインに加えて、または代わりにユーザー名を使用してサインインしたい場合は、それも可能です。メソッドlogin代わりにメソッドloginWithUsernameを呼び出すだけです。次に、 InvalidEmailExceptionをキャッチする代わりに、 UnknownUsernameExceptionとAmbiguousUsernameException両方をキャッチするようにしてください。新しいユーザーのサインアップ方法を説明するセクションにある、ユーザー名の一意性に関する注意事項もお読みください。

メール認証

ユーザーが確認メール内でクリックした URL からセレクターとトークンを抽出します。

 try {
    $ auth -> confirmEmail ( $ _GET [ ' selector ' ], $ _GET [ ' token ' ]);

    echo ' Email address has been verified ' ;
}
catch (  Delight  Auth  InvalidSelectorTokenPairException $ e ) {
    die ( ' Invalid token ' );
}
catch (  Delight  Auth  TokenExpiredException $ e ) {
    die ( ' Token expired ' );
}
catch (  Delight  Auth  UserAlreadyExistsException $ e ) {
    die ( ' Email address already exists ' );
}
catch (  Delight  Auth  TooManyRequestsException $ e ) {
    die ( ' Too many requests ' );
}

確認が成功した後にユーザーが自動的にサインインするようにしたい場合は、 confirmEmailの代わりにconfirmEmailAndSignInを呼び出します。この代替方法では、オプションの 3 番目のパラメータを介して永続的なログインもサポートされます。

成功すると、 confirmEmailとconfirmEmailAndSignIn 2 つのメソッドは両方とも、インデックス 1 に検証されたばかりのユーザーの新しい電子メールアドレスを含む配列を返します。確認が単純なアドレス検証ではなくアドレス変更に関するものである場合、ユーザーの古い電子メールアドレスは配列のインデックス 0 に含まれます。

ユーザーのログイン状態を維持する

Auth#loginとAuth#confirmEmailAndSignInメソッドの 3 番目のパラメーターは、ログインが有効期間の長い Cookie で永続化されるかどうかを制御します。このような永続的なログインでは、ブラウザーセッションがすでに閉じられ、セッション Cookie の有効期限が切れている場合でも、ユーザーは長期間認証されたままになる可能性があります。通常、「ログイン状態を記憶する」または「ログイン状態を維持する」と呼ばれるこの機能を使用して、ユーザーを数週間または数か月間ログイン状態に保つ必要があります。多くのユーザーはこれが便利だと感じますが、デバイスを放置したままにすると安全性が低下する可能性があります。

 if ( $ _POST [ ' remember ' ] == 1 ) {
    // keep logged in for one year
    $ rememberDuration = ( int ) ( 60 * 60 * 24 * 365.25 );
}
else {
    // do not keep logged in after session ends
    $ rememberDuration = null ;
}

// ...

$ auth -> login ( $ _POST [ ' email ' ], $ _POST [ ' password ' ], $ rememberDuration );

// . . .

デフォルトの動作である永続的なログインがなければ、ユーザーはブラウザを閉じるまで、または PHP のsession.cookie_lifetimeおよびsession.gc_maxlifetimeで設定されている限り、ログインしたままになります。

この機能を無効にするには、3 番目のパラメーターを省略するか、 nullに設定します。それ以外の場合は、「私を記憶する」を有効にするかどうかをユーザーに尋ねることができます。これは通常、ユーザーインターフェイスのチェックボックスを使用して行われます。そのチェックボックスからの入力を使用して、 nullと事前定義された期間 (秒単位) のどちらかを決定します (例: 1 年なら60 * 60 * 24 * 365.25 )。

パスワードのリセット（「パスワードを忘れた場合」）

ステップ 1/3: リクエストの開始

 try {
    $ auth -> forgotPassword ( $ _POST [ ' email ' ], function ( $ selector , $ token ) {
        echo ' Send ' . $ selector . ' and ' . $ token . ' to the user (e.g. via email) ' ;
        echo '  For emails, consider using the mail(...) function, Symfony Mailer, Swiftmailer, PHPMailer, etc. ' ;
        echo '  For SMS, consider using a third-party service and a compatible SDK ' ;
    });

    echo ' Request has been generated ' ;
}
catch (  Delight  Auth  InvalidEmailException $ e ) {
    die ( ' Invalid email address ' );
}
catch (  Delight  Auth  EmailNotVerifiedException $ e ) {
    die ( ' Email not verified ' );
}
catch (  Delight  Auth  ResetDisabledException $ e ) {
    die ( ' Password reset is disabled ' );
}
catch (  Delight  Auth  TooManyRequestsException $ e ) {
    die ( ' Too many requests ' );
}

セレクターとトークンを使用して URL を構築し、それをユーザーに送信する必要があります。例:

 $ url = ' https://www.example.com/reset_password?selector= ' . urlencode ( $ selector ) . ' &token= ' . urlencode ( $ token );

パスワードリセット要求のデフォルトの有効期間が機能しない場合は、 Auth#forgotPasswordの 3 番目のパラメーターを使用して、要求が期限切れになるまでのカスタム間隔を秒単位で指定できます。

ステップ 2/3: 試行の検証

次のステップとして、ユーザーは受け取ったリンクをクリックします。 URL からセレクターとトークンを抽出します。

セレクターとトークンのペアが有効な場合は、ユーザーに新しいパスワードを選択させます。

 try {
    $ auth -> canResetPasswordOrThrow ( $ _GET [ ' selector ' ], $ _GET [ ' token ' ]);

    echo ' Put the selector into a "hidden" field (or keep it in the URL) ' ;
    echo ' Put the token into a "hidden" field (or keep it in the URL) ' ;

    echo ' Ask the user for their new password ' ;
}
catch (  Delight  Auth  InvalidSelectorTokenPairException $ e ) {
    die ( ' Invalid token ' );
}
catch (  Delight  Auth  TokenExpiredException $ e ) {
    die ( ' Token expired ' );
}
catch (  Delight  Auth  ResetDisabledException $ e ) {
    die ( ' Password reset is disabled ' );
}
catch (  Delight  Auth  TooManyRequestsException $ e ) {
    die ( ' Too many requests ' );
}

あるいは、エラーメッセージは必要なく、有効性だけを確認したい場合は、もう少し単純なバージョンを使用することもできます。

 if ( $ auth -> canResetPassword ( $ _GET [ ' selector ' ], $ _GET [ ' token ' ])) {
    echo ' Put the selector into a "hidden" field (or keep it in the URL) ' ;
    echo ' Put the token into a "hidden" field (or keep it in the URL) ' ;

    echo ' Ask the user for their new password ' ;
}

ステップ 3/3: パスワードの更新

ユーザーの新しいパスワードを取得したら (残りの 2 つの情報もまだ保持している)、パスワードをリセットできます。

 try {
    $ auth -> resetPassword ( $ _POST [ ' selector ' ], $ _POST [ ' token ' ], $ _POST [ ' password ' ]);

    echo ' Password has been reset ' ;
}
catch (  Delight  Auth  InvalidSelectorTokenPairException $ e ) {
    die ( ' Invalid token ' );
}
catch (  Delight  Auth  TokenExpiredException $ e ) {
    die ( ' Token expired ' );
}
catch (  Delight  Auth  ResetDisabledException $ e ) {
    die ( ' Password reset is disabled ' );
}
catch (  Delight  Auth  InvalidPasswordException $ e ) {
    die ( ' Invalid password ' );
}
catch (  Delight  Auth  TooManyRequestsException $ e ) {
    die ( ' Too many requests ' );
}

パスワードのリセットが成功したときに、各ユーザーが自動的にサインインするようにしますか? Auth Auth#resetPassword Auth#resetPasswordAndSignInを使用するだけで、ユーザーをすぐにログインできます。

ユーザーの ID または電子メールアドレスが必要な場合、たとえばパスワードが正常にリセットされたという通知を送信する場合は、 Auth#resetPasswordの戻り値を使用します。これは、 idとemailという名前の 2 つのエントリを含む配列です。

現在のユーザーのパスワードを変更する

ユーザーが現在ログインしている場合は、パスワードを変更できます。

 try {
    $ auth -> changePassword ( $ _POST [ ' oldPassword ' ], $ _POST [ ' newPassword ' ]);

    echo ' Password has been changed ' ;
}
catch (  Delight  Auth  NotLoggedInException $ e ) {
    die ( ' Not logged in ' );
}
catch (  Delight  Auth  InvalidPasswordException $ e ) {
    die ( ' Invalid password(s) ' );
}
catch (  Delight  Auth  TooManyRequestsException $ e ) {
    die ( ' Too many requests ' );
}

ユーザーに現在の (そしてすぐに古い) パスワードを尋ね、検証のためにそれを要求することは、パスワード変更を処理する場合に推奨される方法です。これを上に示します。

ただし、その確認が必要ないと確信している場合は、 changePassword代わりにchangePasswordWithoutOldPasswordを呼び出し、そのメソッド呼び出しから最初のパラメーターを削除できます (そうしないと古いパスワードが含まれることになります)。

いずれの場合も、ユーザーのパスワードが変更された後は、この重要な変更についてアカウント所有者に通知するアウトオブバンド通知として、ユーザーのアカウントのプライマリ電子メールアドレスに電子メールを送信する必要があります。

現在のユーザーのメールアドレスを変更する

ユーザーが現在ログインしている場合は、電子メールアドレスを変更できます。

 try {
    if ( $ auth -> reconfirmPassword ( $ _POST [ ' password ' ])) {
        $ auth -> changeEmail ( $ _POST [ ' newEmail ' ], function ( $ selector , $ token ) {
            echo ' Send ' . $ selector . ' and ' . $ token . ' to the user (e.g. via email to the *new* address) ' ;
            echo '  For emails, consider using the mail(...) function, Symfony Mailer, Swiftmailer, PHPMailer, etc. ' ;
            echo '  For SMS, consider using a third-party service and a compatible SDK ' ;
        });

        echo ' The change will take effect as soon as the new email address has been confirmed ' ;
    }
    else {
        echo ' We can ' t say if the user is who they claim to be ' ;
    }
}
catch (  Delight  Auth  InvalidEmailException $ e ) {
    die ( ' Invalid email address ' );
}
catch (  Delight  Auth  UserAlreadyExistsException $ e ) {
    die ( ' Email address already exists ' );
}
catch (  Delight  Auth  EmailNotVerifiedException $ e ) {
    die ( ' Account not verified ' );
}
catch (  Delight  Auth  NotLoggedInException $ e ) {
    die ( ' Not logged in ' );
}
catch (  Delight  Auth  TooManyRequestsException $ e ) {
    die ( ' Too many requests ' );
}

電子メール検証の場合、セレクターとトークンを使用して URL を構築し、それをユーザーに送信する必要があります。例:

 $ url = ' https://www.example.com/verify_email?selector= ' . urlencode ( $ selector ) . ' &token= ' . urlencode ( $ token );

メールアドレスの変更リクエストが行われた後、または変更がユーザーによって確認された後、アカウント所有者に次のことを通知するアウトオブバンド通知として、アカウントの以前のメールアドレスにメールを送信する必要があります。この重大な変化。

注:ユーザーの電子メールアドレスへの変更は、予想どおり、ローカルセッションで直ちに有効になります。ただし、他のセッション (他のデバイスなど) では、変更が有効になるまでに最大 5 分かかる場合があります。これによりパフォーマンスが向上し、通常は問題が発生しません。それでもこの動作を変更したい場合は、 $sessionResyncIntervalという名前の引数としてAuthコンストラクターに渡す値を単純に減らします (または場合によっては増やします)。

確認リクエストの再送信

以前の確認リクエストをユーザーに配信できなかった場合、またはユーザーがそのリクエストを見逃した場合、または単にこれ以上待ちたくない場合は、次のように以前のリクエストを再送信できます。

 try {
    $ auth -> resendConfirmationForEmail ( $ _POST [ ' email ' ], function ( $ selector , $ token ) {
        echo ' Send ' . $ selector . ' and ' . $ token . ' to the user (e.g. via email) ' ;
        echo '  For emails, consider using the mail(...) function, Symfony Mailer, Swiftmailer, PHPMailer, etc. ' ;
        echo '  For SMS, consider using a third-party service and a compatible SDK ' ;
    });

    echo ' The user may now respond to the confirmation request (usually by clicking a link) ' ;
}
catch (  Delight  Auth  ConfirmationRequestNotFound $ e ) {
    die ( ' No earlier request found that could be re-sent ' );
}
catch (  Delight  Auth  TooManyRequestsException $ e ) {
    die ( ' There have been too many requests -- try again later ' );
}

電子メールアドレスではなく ID でユーザーを指定したい場合は、次のようにすることも可能です。

 try {
    $ auth -> resendConfirmationForUserId ( $ _POST [ ' userId ' ], function ( $ selector , $ token ) {
        echo ' Send ' . $ selector . ' and ' . $ token . ' to the user (e.g. via email) ' ;
        echo '  For emails, consider using the mail(...) function, Symfony Mailer, Swiftmailer, PHPMailer, etc. ' ;
        echo '  For SMS, consider using a third-party service and a compatible SDK ' ;
    });

    echo ' The user may now respond to the confirmation request (usually by clicking a link) ' ;
}
catch (  Delight  Auth  ConfirmationRequestNotFound $ e ) {
    die ( ' No earlier request found that could be re-sent ' );
}
catch (  Delight  Auth  TooManyRequestsException $ e ) {
    die ( ' There have been too many requests -- try again later ' );
}

通常、たとえば次のように、セレクターとトークンを使用して URL を構築し、ユーザーに送信する必要があります。

 $ url = ' https://www.example.com/verify_email?selector= ' . urlencode ( $ selector ) . ' &token= ' . urlencode ( $ token );

ログアウト

 $ auth -> logOut ();

// or

try {
    $ auth -> logOutEverywhereElse ();
}
catch (  Delight  Auth  NotLoggedInException $ e ) {
    die ( ' Not logged in ' );
}

// or

try {
    $ auth -> logOutEverywhere ();
}
catch (  Delight  Auth  NotLoggedInException $ e ) {
    die ( ' Not logged in ' );
}

さらに、カスタム情報もセッションに保存しており、その情報を削除したい場合は、2 番目のメソッドを呼び出してセッション全体を破棄できます。

 $ auth -> destroySession ();

注:グローバルログアウトは、予想どおり、ローカルセッションで直ちに有効になります。ただし、他のセッション (他のデバイスなど) では、変更が有効になるまでに最大 5 分かかる場合があります。これによりパフォーマンスが向上し、通常は問題が発生しません。それでもこの動作を変更したい場合は、 $sessionResyncIntervalという名前の引数としてAuthコンストラクターに渡す値を単純に減らします (または場合によっては増やします)。

ユーザー情報へのアクセス

ログイン状態

 if ( $ auth -> isLoggedIn ()) {
    echo ' User is signed in ' ;
}
else {
    echo ' User is not signed in yet ' ;
}

このメソッドの短縮形/別名は$auth->check()です。

ユーザーID

 $ id = $ auth -> getUserId ();

ユーザーが現在サインインしていない場合は、 nullを返します。

このメソッドの短縮形/エイリアスは$auth->id()です。

電子メールアドレス

 $ email = $ auth -> getEmail ();

ユーザーが現在サインインしていない場合は、 nullを返します。

表示名

 $ username = $ auth -> getUsername ();

ユーザー名はオプションであり、登録時にユーザー名を指定した場合のみ存在することに注意してください。

ユーザーが現在サインインしていない場合は、 nullを返します。

ステータス情報

 if ( $ auth -> isNormal ()) {
    echo ' User is in default state ' ;
}

if ( $ auth -> isArchived ()) {
    echo ' User has been archived ' ;
}

if ( $ auth -> isBanned ()) {
    echo ' User has been banned ' ;
}

if ( $ auth -> isLocked ()) {
    echo ' User has been locked ' ;
}

if ( $ auth -> isPendingReview ()) {
    echo ' User is pending review ' ;
}

if ( $ auth -> isSuspended ()) {
    echo ' User has been suspended ' ;
}

ユーザーが「記憶」されているかどうかを確認する

 if ( $ auth -> isRemembered ()) {
    echo ' User did not sign in but was logged in through their long-lived cookie ' ;
}
else {
    echo ' User signed in manually ' ;
}

ユーザーが現在サインインしていない場合は、 nullを返します。

IPアドレス

 $ ip = $ auth -> getIpAddress ();

追加のユーザー情報

このライブラリのあらゆる目的への適合性と完全な再利用性を維持するために、ユーザー情報用の追加のバンドル列は付属していません。ただし、もちろん、追加のユーザー情報がないわけではありません。

このライブラリを、保守可能かつ再利用可能な方法でカスタムユーザー情報用の独自のテーブルとともに使用する方法は次のとおりです。

カスタムユーザー情報を保存するカスタムデータベーステーブルを任意の数追加します (例: profilesという名前のテーブル)。
registerメソッド (新しいユーザーの ID を返す) を呼び出すたびに、その後、カスタムデータベーステーブルに入力する独自のロジックを追加します。

カスタムユーザー情報が必要になることがほとんどない場合は、必要に応じて取得するだけで済みます。ただし、より頻繁に必要になる場合は、セッションデータに含めることをお勧めします。次の方法は、信頼性の高い方法でデータをロードしてアクセスする方法です。

 function getUserInfo (  Delight  Auth  Auth $ auth ) {
    if (! $ auth -> isLoggedIn ()) {
        return null ;
    }

    if (! isset ( $ _SESSION [ ' _internal_user_info ' ])) {
        // TODO : load your custom user information and assign it to the session variable below
        // $ _SESSION [ ' _internal_user_info' ] = ...
    }

    return $ _SESSION [ ' _internal_user_info ' ];
}

ユーザーのパスワードを再確認する

ユーザーの身元を再度確認したい場合、たとえばユーザーが何らかの「危険な」アクションの実行を許可される前に、パスワードを再度検証して、そのユーザーが本当に本人であることを確認する必要があります。

たとえば、ユーザーが有効期間の長い Cookie によって記憶されており、 Auth#isRemembered true返した場合、これはユーザーがかなり長い間パスワードを入力していない可能性があることを意味します。その場合は、パスワードを再確認してください。

 try {
    if ( $ auth -> reconfirmPassword ( $ _POST [ ' password ' ])) {
        echo ' The user really seems to be who they claim to be ' ;
    }
    else {
        echo ' We can ' t say if the user is who they claim to be ' ;
    }
}
catch (  Delight  Auth  NotLoggedInException $ e ) {
    die ( ' The user is not signed in ' );
}
catch (  Delight  Auth  TooManyRequestsException $ e ) {
    die ( ' Too many requests ' );
}

役割（またはグループ）

すべてのユーザーは任意の数のロールを持つことができ、これを使用して承認を実装し、アクセス制御を調整できます。

ユーザーはロールをまったく持たない場合もあり (デフォルトでロールが割り当てられます)、ロールを 1 つだけ持つことも、ロールの任意の組み合わせを持たせることもできます。

役割の確認

 if ( $ auth -> hasRole ( Delight  Auth Role:: SUPER_MODERATOR )) {
    echo ' The user is a super moderator ' ;
}

// or

if ( $ auth -> hasAnyRole ( Delight  Auth Role:: DEVELOPER ,  Delight  Auth Role:: MANAGER )) {
    echo ' The user is either a developer, or a manager, or both ' ;
}

// or

if ( $ auth -> hasAllRoles ( Delight  Auth Role:: DEVELOPER ,  Delight  Auth Role:: MANAGER )) {
    echo ' The user is both a developer and a manager ' ;
}

hasRoleメソッドは引数として 1 つのロールのみを受け取りますが、 hasAnyRoleとhasAllRoles 2 つのメソッドは、チェックしたい任意の数のロールを受け取ることができます。

あるいは、ユーザーに割り当てられているすべてのロールのリストを取得することもできます。

 $ auth -> getRoles ();

利用可能な役割

 Delight  Auth Role:: ADMIN ;
 Delight  Auth Role:: AUTHOR ;
 Delight  Auth Role:: COLLABORATOR ;
 Delight  Auth Role:: CONSULTANT ;
 Delight  Auth Role:: CONSUMER ;
 Delight  Auth Role:: CONTRIBUTOR ;
 Delight  Auth Role:: COORDINATOR ;
 Delight  Auth Role:: CREATOR ;
 Delight  Auth Role:: DEVELOPER ;
 Delight  Auth Role:: DIRECTOR ;
 Delight  Auth Role:: EDITOR ;
 Delight  Auth Role:: EMPLOYEE ;
 Delight  Auth Role:: MAINTAINER ;
 Delight  Auth Role:: MANAGER ;
 Delight  Auth Role:: MODERATOR ;
 Delight  Auth Role:: PUBLISHER ;
 Delight  Auth Role:: REVIEWER ;
 Delight  Auth Role:: SUBSCRIBER ;
 Delight  Auth Role:: SUPER_ADMIN ;
 Delight  Auth Role:: SUPER_EDITOR ;
 Delight  Auth Role:: SUPER_MODERATOR ;
 Delight  Auth Role:: TRANSLATOR ;

これらのロールのいずれかを使用し、必要のないロールは無視できます。上記のリストは、次の 3 つの形式のいずれかでプログラム的に取得することもできます。

 Delight  Auth Role:: getMap ();
// or
 Delight  Auth Role:: getNames ();
// or
 Delight  Auth Role:: getValues ();

権限 (またはアクセス権、特権、または機能)

各ユーザーの権限は、コードベース全体でロール要件が指定される方法でエンコードされます。これらの要件が特定のユーザーのロールのセットを使用して評価される場合、その結果、暗黙的にチェックされる権限が得られます。

大規模なプロジェクトの場合、多くの場合、権限の定義を 1 か所で管理することが推奨されます。次に、ビジネスロジック内のロールをチェックするのではなく、個々の権限をチェックします。その概念は次のように実装できます。

 function canEditArticle (  Delight  Auth  Auth $ auth ) {
    return $ auth -> hasAnyRole (
         Delight  Auth Role:: MODERATOR ,
         Delight  Auth Role:: SUPER_MODERATOR ,
         Delight  Auth Role:: ADMIN ,
         Delight  Auth Role:: SUPER_ADMIN
    );
}

// . . .

if ( canEditArticle ( $ auth )) {
    echo ' The user can edit articles here ' ;
}

// . . .

if ( canEditArticle ( $ auth )) {
    echo ' ... and here ' ;
}

// . . .

if ( canEditArticle ( $ auth )) {
    echo ' ... and here ' ;
}

ご覧のとおり、特定のユーザーが記事を編集できるかどうかの権限は、中央の場所に保存されています。この実装には、次の 2 つの大きな利点があります。

どのユーザーが記事を編集できるかを知りたい場合、さまざまな場所でビジネスロジックをチェックする必要はなく、特定の権限が定義されている場所を確認するだけで済みます。また、記事を編集できるユーザーを変更したい場合も、コードベース全体ではなく、1 か所で変更するだけで済みます。

ただし、これにはアクセス制限を初めて実装する場合に若干のオーバーヘッドが発生するため、プロジェクトにとって価値があるかどうかはわかりません。

カスタムロール名

含まれているロールの名前が機能しない場合は、次のように、独自の識別子を使用して任意の数のロールのエイリアスを作成できます。

 namespace My  Namespace ;

final class MyRole {

    const CUSTOMER_SERVICE_AGENT =  Delight  Auth Role:: REVIEWER ;
    const FINANCIAL_DIRECTOR =  Delight  Auth Role:: COORDINATOR ;

    private function __construct () {}

}

上記の例では、次のように使用できます。

 My  Namespace MyRole:: CUSTOMER_SERVICE_AGENT ;
// and
 My  Namespace MyRole:: FINANCIAL_DIRECTOR ;

の代わりに

 Delight  Auth Role:: REVIEWER ;
// and
 Delight  Auth Role:: COORDINATOR ;

含まれる単一のロールをカスタム名を持つ複数のロールにエイリアスしないように注意してください。

パスワードのリセットの有効化または無効化

電子メールによるパスワードのリセットは、ほとんどのユーザーが時々役立つ便利な機能ですが、この機能が利用できるということは、サービス上のアカウントの安全性は、ユーザーに関連付けられている電子メールアカウントと同等であることを意味します。

セキュリティを重視する (および経験豊富な) ユーザーに、セキュリティを強化するために自分のアカウントのパスワードリセットを無効にする (後で再度有効にする) 機能を提供できます。

 try {
    if ( $ auth -> reconfirmPassword ( $ _POST [ ' password ' ])) {
        $ auth -> setPasswordResetEnabled ( $ _POST [ ' enabled ' ] == 1 );

        echo ' The setting has been changed ' ;
    }
    else {
        echo ' We can ' t say if the user is who they claim to be ' ;
    }
}
catch (  Delight  Auth  NotLoggedInException $ e ) {
    die ( ' The user is not signed in ' );
}
catch (  Delight  Auth  TooManyRequestsException $ e ) {
    die ( ' Too many requests ' );
}

この設定の現在の値を確認するには、からの戻り値を使用します。

 $ auth -> isPasswordResetEnabled ();

ユーザーインターフェイスの正しいデフォルトオプションを確認してください。機能の制限については、この値を確認する必要はありません。制限は自動的に適用されます。

スロットリングまたはレート制限

このライブラリによって提供されるすべてのメソッドは、クライアントからの過剰な数のリクエストから自動的に保護されます。必要な場合は、コンストラクターに渡される$throttlingパラメーターを使用して、この保護を (一時的に) 無効にすることができます。

外部の機能やメソッド (独自のコード内の機能など) もスロットルまたはレート制限したい場合は、スロットルとレート制限用の組み込みヘルパーメソッドを利用できます。

 try {
    // throttle the specified resource or feature to * 3 * requests per * 60 * seconds
    $ auth -> throttle ([ ' my-resource-name ' ], 3 , 60 );

    echo ' Do something with the resource or feature ' ;
}
catch (  Delight  Auth  TooManyRequestsException $ e ) {
    // operation cancelled

    http_response_code ( 429 );
    exit ;
}

リソースまたは機能の保護が別の属性にさらに依存する必要がある場合 (たとえば、IP アドレスごとに何かを個別に追跡する場合)、リソースの説明に次のようなデータを追加するだけです。

[ ' my-resource-name ' , $ _SERVER [ ' REMOTE_ADDR ' ] ]
// instead of
// [ ' my-resource-name' ]

4 番目の引数としてバースト係数を指定することで、ピーク需要時にアクティビティの短期間のバーストを許可できます。たとえば、値5では、一般に受け入れられているレベルと比較して、5 倍のアクティビティの一時的なバーストが許可されます。

場合によっては、スロットルまたはレート制限をシミュレートしたいだけかもしれません。これにより、アクティビティトラッカーを実際に変更せずに、アクションが許可されるかどうかを確認できます。これを行うには、5 番目の引数としてtrueを渡すだけです。

注:インスタンスのスロットリングを無効にすると (コンストラクターに渡された$throttlingパラメーターを使用)、自動内部保護と、独自のアプリケーションコードでのAuth#throttle呼び出しの効果の両方がオフになります。ただし、特定のAuth#throttle呼び出しで、オプションの$forceパラメーターをtrueに設定します。

管理 (ユーザーの管理)

管理インターフェイスは$auth->admin()経由で利用できます。以下に示すように、このインターフェイスでさまざまなメソッドを呼び出すことができます。

このインターフェイスへのアクセスを公開する前に、安全なアクセス制御を実装することを忘れないでください。たとえば、管理者ロールを持つログインユーザーのみにこのインターフェイスへのアクセスを提供したり、プライベートスクリプトでのみインターフェイスを使用したりできます。

新しいユーザーの作成

 try {
    $ userId = $ auth -> admin ()-> createUser ( $ _POST [ ' email ' ], $ _POST [ ' password ' ], $ _POST [ ' username ' ]);

    echo ' We have signed up a new user with the ID ' . $ userId ;
}
catch (  Delight  Auth  InvalidEmailException $ e ) {
    die ( ' Invalid email address ' );
}
catch (  Delight  Auth  InvalidPasswordException $ e ) {
    die ( ' Invalid password ' );
}
catch (  Delight  Auth  UserAlreadyExistsException $ e ) {
    die ( ' User already exists ' );
}

3 番目のパラメータのユーザー名はオプションです。ユーザー名を管理したくない場合は、そこにnullを渡すことができます。

一方、一意のユーザー名を強制したい場合は、 createUser代わりにcreateUserWithUniqueUsernameを呼び出すだけで、 DuplicateUsernameExceptionをキャッチできるように準備してください。

ユーザーの削除

ID によるユーザーの削除:

 try {
    $ auth -> admin ()-> deleteUserById ( $ _POST [ ' id ' ]);
}
catch (  Delight  Auth  UnknownIdException $ e ) {
    die ( ' Unknown ID ' );
}

電子メールアドレスによるユーザーの削除:

 try {
    $ auth -> admin ()-> deleteUserByEmail ( $ _POST [ ' email ' ]);
}
catch (  Delight  Auth  InvalidEmailException $ e ) {
    die ( ' Unknown email address ' );
}

ユーザー名でユーザーを削除する:

 try {
    $ auth -> admin ()-> deleteUserByUsername ( $ _POST [ ' username ' ]);
}
catch (  Delight  Auth  UnknownUsernameException $ e ) {
    die ( ' Unknown username ' );
}
catch (  Delight  Auth  AmbiguousUsernameException $ e ) {
    die ( ' Ambiguous username ' );
}

登録ユーザーのリストを取得する

すべてのユーザーのリストを取得する場合、要件はプロジェクトやユースケースによって大きく異なり、カスタマイズが一般的です。たとえば、さまざまな列を取得したり、関連するテーブルを結合したり、特定の条件でフィルタリングしたり、結果の並べ替え方法を (さまざまな方向に) 変更したり、結果の数を制限したり (オフセットを提供しながら) することができます。

このため、単一のカスタム SQL クエリを使用する方が簡単です。以下から始めてください。

 SELECT id, email, username, status, verified, roles_mask, registered, last_login FROM users;

ユーザーへの役割の割り当て

 try {
    $ auth -> admin ()-> addRoleForUserById ( $ userId ,  Delight  Auth Role:: ADMIN );
}
catch (  Delight  Auth  UnknownIdException $ e ) {
    die ( ' Unknown user ID ' );
}

// or

try {
    $ auth -> admin ()-> addRoleForUserByEmail ( $ userEmail ,  Delight  Auth Role:: ADMIN );
}
catch (  Delight  Auth  InvalidEmailException $ e ) {
    die ( ' Unknown email address ' );
}

// or

try {
    $ auth -> admin ()-> addRoleForUserByUsername ( $ username ,  Delight  Auth Role:: ADMIN );
}
catch (  Delight  Auth  UnknownUsernameException $ e ) {
    die ( ' Unknown username ' );
}
catch (  Delight  Auth  AmbiguousUsernameException $ e ) {
    die ( ' Ambiguous username ' );
}

注:ユーザーの役割セットに対する変更が有効になるまでに最大 5 分かかる場合があります。これによりパフォーマンスが向上し、通常は問題が発生しません。それでもこの動作を変更したい場合は、 $sessionResyncIntervalという名前の引数としてAuthコンストラクターに渡す値を単純に減らします (または場合によっては増やします)。

ユーザーから役割を奪う

 try {
    $ auth -> admin ()-> removeRoleForUserById ( $ userId ,  Delight  Auth Role:: ADMIN );
}
catch (  Delight  Auth  UnknownIdException $ e ) {
    die ( ' Unknown user ID ' );
}

// or

try {
    $ auth -> admin ()-> removeRoleForUserByEmail ( $ userEmail ,  Delight  Auth Role:: ADMIN );
}
catch (  Delight  Auth  InvalidEmailException $ e ) {
    die ( ' Unknown email address ' );
}

// or

try {
    $ auth -> admin ()-> removeRoleForUserByUsername ( $ username ,  Delight  Auth Role:: ADMIN );
}
catch (  Delight  Auth  UnknownUsernameException $ e ) {
    die ( ' Unknown username ' );
}
catch (  Delight  Auth  AmbiguousUsernameException $ e ) {
    die ( ' Ambiguous username ' );
}

役割の確認

 try {
    if ( $ auth -> admin ()-> doesUserHaveRole ( $ userId ,  Delight  Auth Role:: ADMIN )) {
        echo ' The specified user is an administrator ' ;
    }
    else {
        echo ' The specified user is not an administrator ' ;
    }
}
catch (  Delight  Auth  UnknownIdException $ e ) {
    die ( ' Unknown user ID ' );
}

あるいは、ユーザーに割り当てられているすべてのロールのリストを取得することもできます。

 $ auth -> admin ()-> getRolesForUserById ( $ userId );

ユーザーの偽装 (ユーザーとしてログイン)

 try {
    $ auth -> admin ()-> logInAsUserById ( $ _POST [ ' id ' ]);
}
catch (  Delight  Auth  UnknownIdException $ e ) {
    die ( ' Unknown ID ' );
}
catch (  Delight  Auth  EmailNotVerifiedException $ e ) {
    die ( ' Email address not verified ' );
}

// or

try {
    $ auth -> admin ()-> logInAsUserByEmail ( $ _POST [ ' email ' ]);
}
catch (  Delight  Auth  InvalidEmailException $ e ) {
    die ( ' Unknown email address ' );
}
catch (  Delight  Auth  EmailNotVerifiedException $ e ) {
    die ( ' Email address not verified ' );
}

// or

try {
    $ auth -> admin ()-> logInAsUserByUsername ( $ _POST [ ' username ' ]);
}
catch (  Delight  Auth  UnknownUsernameException $ e ) {
    die ( ' Unknown username ' );
}
catch (  Delight  Auth  AmbiguousUsernameException $ e ) {
    die ( ' Ambiguous username ' );
}
catch (  Delight  Auth  EmailNotVerifiedException $ e ) {
    die ( ' Email address not verified ' );
}

ユーザーのパスワードを変更する

 try {
    $ auth -> admin ()-> changePasswordForUserById ( $ _POST [ ' id ' ], $ _POST [ ' newPassword ' ]);
}
catch (  Delight  Auth  UnknownIdException $ e ) {
    die ( ' Unknown ID ' );
}
catch (  Delight  Auth  InvalidPasswordException $ e ) {
    die ( ' Invalid password ' );
}

// or

try {
    $ auth -> admin ()-> changePasswordForUserByUsername ( $ _POST [ ' username ' ], $ _POST [ ' newPassword ' ]);
}
catch (  Delight  Auth  UnknownUsernameException $ e ) {
    die ( ' Unknown username ' );
}
catch (  Delight  Auth  AmbiguousUsernameException $ e ) {
    die ( ' Ambiguous username ' );
}
catch (  Delight  Auth  InvalidPasswordException $ e ) {
    die ( ' Invalid password ' );
}

クッキー

このライブラリは、クライアントの状態を維持するために 2 つの Cookie を使用します。1 つ目の Cookie は、次のコマンドを使用して名前を取得できます。

 session_name ();

一般的な (必須の) セッション Cookie です。 2 番目 (オプション) Cookie は永続的なログインにのみ使用され、その名前は次のように取得できます。

 Delight  Auth Auth:: createRememberCookieName ();

ライブラリの Cookie の名前を変更する

次のいずれかの方法で、このライブラリで使用されるセッション Cookie の名前を推奨順に変更できます。

PHP 構成 ( php.ini ) で、 session.nameディレクティブを含む行を見つけ、その値をsession_v1のような値に変更します。次のようにします。
```
 session.name = session_v1
```
アプリケーションのできるだけ早い段階で、 Authインスタンスを作成する前に、次のようにini_set呼び出してsession.name session_v1ような名前に変更します。
```
 ini_set ( ' session.name ' , ' session_v1 ' );
```
これを機能させるには、PHP 設定 ( php.ini ) でsession.auto_startを0に設定する必要があります。
アプリケーションのできるだけ早い段階で、 Authインスタンスを作成する前に、次のようにsession_v1のような引数を指定してsession_nameを呼び出します。
```
 session_name ( ' session_v1 ' );
```
これを機能させるには、PHP 設定 ( php.ini ) でsession.auto_startを0に設定する必要があります。

セッション Cookie の名前を変更すると、永続ログイン用の Cookie の名前も自動的に変更されます。

Cookie のドメインスコープの定義

Cookie のdomain属性は、Cookie がどのドメイン (およびどのサブドメイン) に対して有効であるかを制御し、ユーザーのセッションと認証状態がどこで利用可能になるかを制御します。

推奨されるデフォルトは空の文字列です。これは、Cookie が存在する可能性のあるサブドメインを除き、正確な現在のホストに対してのみ有効であることを意味します。異なるサブドメイン間で Cookie を共有する必要がある場合にのみ、異なる値を使用してください。多くの場合、ベアドメインとwwwサブドメインの間で Cookie を共有する必要がありますが、他のサブドメインのセット間でも Cookie を共有したい場合があります。

どのサブドメインのセットを選択する場合でも、Cookie の属性を、必要なサブドメインをすべて含む最も具体的なドメイン名に設定する必要があります。たとえば、 example.comとwww.example.comの間で Cookie を共有するには、属性をexample.comに設定します。ただし、 sub1.app.example.comとsub2.app.example.comの間で Cookie を共有したい場合は、属性をapp.example.comに設定する必要があります。明示的に指定されたドメイン名には、存在する可能性のあるすべてのサブドメインが常に含まれます。

推奨順に、次のいずれかの方法で属性を変更できます。

PHP 設定 ( php.ini ) で、 session.cookie_domainディレクティブを含む行を見つけ、その値を必要に応じて変更します。例:
```
 session.cookie_domain = example.com
```
アプリケーションのできるだけ早い段階で、 Authインスタンスを作成する前に、 ini_setを呼び出してsession.cookie_domainディレクティブの値を必要に応じて変更します。例:
```
 ini_set ( ' session.cookie_domain ' , ' example.com ' );
```
これを機能させるには、PHP 設定 ( php.ini ) でsession.auto_startを0に設定する必要があります。

Cookie が使用できるパスを制限する

Cookie のpath属性は、Cookie が有効となるディレクトリ (およびサブディレクトリ)、つまりユーザーのセッションと認証状態が利用できる場所を制御します。

ほとんどの場合、ルートディレクトリから始まるすべてのパス、つまり任意のディレクトリとファイルで Cookie を使用できるようにする必要があります。これは、属性の値/が行うことです。これは、推奨されるデフォルトでもあります。この属性を別の値 (例: /path/to/subfolderに変更する必要があるのは、Cookie を使用できるディレクトリを制限する場合 (例: 複数のアプリケーションを並べて、異なるディレクトリでホストする場合) です。同じドメイン名。

推奨順に、次のいずれかの方法で属性を変更できます。

PHP 設定 ( php.ini ) で、 session.cookie_pathディレクティブを含む行を見つけ、その値を必要に応じて変更します。例:
```
 session.cookie_path = /
```
アプリケーションのできるだけ早い段階で、 Authインスタンスを作成する前に、 ini_setを呼び出してsession.cookie_pathディレクティブの値を必要に応じて変更します。例:
```
 ini_set ( ' session.cookie_path ' , ' / ' );
```
これを機能させるには、PHP 設定 ( php.ini ) でsession.auto_startを0に設定する必要があります。

クライアント側スクリプトによる Cookie へのアクセスの制御

httponly属性を使用すると、クライアント側のスクリプト (JavaScript など) が Cookie にアクセスできるかどうかを制御できます。セキュリティ上の理由から、Cookie へのスクリプトアクセスを拒否することが最善です。これにより、たとえば、アプリケーションに対する XSS 攻撃が成功した場合の被害が軽減されます。

したがって、本当に JavaScript から Cookie にアクセスする必要があり、より良い解決策が見つからないというまれなケースを除いて、常にhttponly 1に設定する必要があります。このような場合は、属性を0に設定しますが、その結果に注意してください。

推奨順に、次のいずれかの方法で属性を変更できます。

PHP 設定 ( php.ini ) で、 session.cookie_httponlyディレクティブを含む行を見つけ、その値を必要に応じて変更します。例:
```
 session.cookie_httponly = 1
```
アプリケーションのできるだけ早い段階で、 Authインスタンスを作成する前に、 ini_setを呼び出して、 session.cookie_httponlyディレクティブの値を必要に応じて変更します。たとえば、次のようになります。
```
 ini_set ( ' session.cookie_httponly ' , 1 );
```
これを機能させるには、PHP 設定 ( php.ini ) でsession.auto_startを0に設定する必要があります。

Cookie のトランスポートセキュリティの構成

secure属性を使用すると、プレーン HTTP を含む任意の接続で Cookie を送信するかどうか、または安全な接続、つまり HTTPS (SSL/TLS を使用) を要求するかどうかを制御できます。前者の (安全性の低い) モードは属性を0に設定することで選択でき、後者の (より安全な) モードは属性を1に設定することで選択できます。

明らかに、これはすべてのページを HTTPS 経由のみで提供できるかどうかにのみ依存します。可能であれば、属性を1に設定し、安全なプロトコルおよび HTTP Strict Transport Security (HSTS) への HTTP リダイレクトと組み合わせてください。それ以外の場合は、属性を0に設定したままにする必要がある場合があります。

推奨順に、次のいずれかの方法で属性を変更できます。

PHP 設定 ( php.ini ) で、 session.cookie_secureディレクティブを含む行を見つけ、その値を必要に応じて変更します。例:
```
 session.cookie_secure = 1
```
アプリケーションのできるだけ早い段階で、 Authインスタンスを作成する前に、 ini_setを呼び出してsession.cookie_secureディレクティブの値を必要に応じて変更します。たとえば、次のようになります。
```
 ini_set ( ' session.cookie_secure ' , 1 );
```
これを機能させるには、PHP 設定 ( php.ini ) でsession.auto_startを0に設定する必要があります。

公共事業

ランダムな文字列の作成

 $ length = 24 ;
$ randomStr =  Delight  Auth Auth:: createRandomString ( $ length );

RFC 4122 に従って UUID v4 を作成する

 $ uuid =  Delight  Auth Auth:: createUuid ();

セッションデータの読み取りと書き込み

セッションデータを簡単に読み書きする方法の詳細については、デフォルトで含まれているセッションライブラリのドキュメントを参照してください。

よくある質問

パスワードのハッシュ化についてはどうですか?

すべてのパスワードまたは認証トークンは、「bcrypt」関数を使用して自動的にハッシュされます。この関数は「Blowfish」暗号に基づいており、（現在でも）現在最も強力なパスワードハッシュ関数の 1 つと考えられています。「bcrypt」は 1,024 回の反復、つまり「コスト」係数 10 で使用されます。ランダムな「ソルト」も自動的に適用されます。

この設定は、データベーステーブルusersのハッシュを確認することで確認できます。上記の設定が当てはまる場合、 usersテーブル内のすべてのパスワードハッシュは、プレフィックス$2$10$ 、 $2a$10$ 、または$2y$10$で始まる必要があります。

将来的に新しいアルゴリズム (Argon2 など) が導入される可能性がある場合、ユーザーがサインインするかパスワードを変更するたびに、このライブラリは既存のパスワードハッシュの「アップグレード」を自動的に処理します。

カスタムパスワード要件を実装するにはどうすればよいですか?

通常、パスワードの最小長を強制することは良い考えです。それとは別に、辞書の単語や一般的に使用されるパスワードがアプリケーションで使用されるのを防ぐために、潜在的なパスワードが何らかのブラックリストに含まれているかどうかを調べたい場合があります。ブラックリストはデータベースまたはファイルで管理できます。

最大限の柔軟性と使いやすさを実現するために、このライブラリはパスワード要件自体の追加チェックを含まないように設計されていますが、代わりにライブラリメソッドへの関連する呼び出しに独自のチェックをラップできるようになりました。例：

 function isPasswordAllowed ( $ password ) {
    if ( strlen ( $ password ) < 8 ) {
        return false ;
    }

    $ blacklist = [ ' password1 ' , ' 123456 ' , ' qwerty ' ];

    if ( in_array ( $ password , $ blacklist )) {
        return false ;
    }

    return true ;
}

if ( isPasswordAllowed ( $ password )) {
    $ auth -> register ( $ email , $ password );
}

セッションで動作する他のライブラリを使用すると問題が発生するのはなぜですか?

他のライブラリをロードする前に、最初にこのライブラリをロードし、最初にAuthインスタンスを作成してみてください。それ以外に、ここで私たちができることはおそらくあまりありません。

他のサイトが私のサイトをフレーム化または埋め込むことができないのはなぜですか?

他のユーザーがあなたのサイトを<frame> 、 <iframe> 、 <object> 、 <embed>または<applet>要素に含めることを許可したい場合は、デフォルトのクリックジャッキング防止を無効にする必要があります。

 header_remove ( ' X-Frame-Options ' );

例外

このライブラリは、問題を示すために 2 種類の例外をスローします。

AuthExceptionとそのサブクラスは、メソッドが正常に完了しない場合にスローされます。これらの例外には、対応する必要がある通常のエラー応答が含まれるため、常にキャッチする必要があります。
AuthErrorとそのサブクラスは、内部に問題がある場合、またはライブラリが正しくインストールされていない場合にスローされます。これらの例外をキャッチしないでください。

一般的なアドバイス

すべてのページを HTTPS のみで提供します。つまり、単一のリクエストごとに SSL/TLS を使用します。
パスワード（10文字など）の最小長さを強制する必要がありますが、少なくとも100文字以下ではありません。さらに、許可された文字のセットを制限しないでください。
サインイン中に「Remember Me」機能が有効または無効になっているユーザーが記憶されたときはいつでも、パスワードを入力してログインしなかったため、重要な機能に再認証が必要です。
ユーザーに、単一のパス単語の代わりに、パスフレーズ、つまり単語の組み合わせ、さらには完全な文章を使用するように勧めます。
ユーザーのパスワードマネージャーが正しく作業しないようにしないでください。したがって、標準のフォームフィールドのみを使用し、コピーと貼り付けを防止しないでください。
機密性の高いアカウント操作を実行する前に（ユーザーのメールアドレスの変更、ユーザーのアカウントの削除）、常に再認証が必要です。つまり、ユーザーがログイン資格情報をもう一度確認する必要があります。
高セキュリティアプリケーション用のオンラインパスワードリセット機能（「パスワードを忘れた」）を提供しないでください。
高セキュリティアプリケーションの場合、電子メールアドレスを識別子として使用しないでください。代わりに、アプリケーションと秘密に固有の識別子を選択します。たとえば、内部の顧客番号などです。

貢献する

すべての貢献を歓迎します!貢献したい場合は、最初に問題を作成して、機能、問題、または質問を議論できるようにしてください。

ライセンス

このプロジェクトは、MITライセンスの条件に基づいてライセンスされています。

拡大する

PHP Auth

認証

なぜこれが必要なのでしょうか?

要件

インストール

アップグレード中

使用法

新しいインスタンスの作成

登録（サインアップ）

ログイン（サインイン）

メール認証

ユーザーのログイン状態を維持する

パスワードのリセット（「パスワードを忘れた場合」）

ステップ 1/3: リクエストの開始

ステップ 2/3: 試行の検証

ステップ 3/3: パスワードの更新

現在のユーザーのパスワードを変更する

現在のユーザーのメールアドレスを変更する

確認リクエストの再送信

ログアウト

ユーザー情報へのアクセス

ログイン状態

ユーザーID

電子メールアドレス

表示名

ステータス情報

ユーザーが「記憶」されているかどうかを確認する

IPアドレス

追加のユーザー情報

ユーザーのパスワードを再確認する

役割（またはグループ）

役割の確認

利用可能な役割

権限 (またはアクセス権、特権、または機能)

カスタムロール名

パスワードのリセットの有効化または無効化

スロットリングまたはレート制限

管理 (ユーザーの管理)

新しいユーザーの作成

ユーザーの削除

登録ユーザーのリストを取得する

ユーザーへの役割の割り当て

ユーザーから役割を奪う

役割の確認

ユーザーの偽装 (ユーザーとしてログイン)

ユーザーのパスワードを変更する

クッキー

ライブラリの Cookie の名前を変更する

Cookie のドメイン スコープの定義

Cookie が使用できるパスを制限する

クライアント側スクリプトによる Cookie へのアクセスの制御

Cookie のトランスポート セキュリティの構成

公共事業

ランダムな文字列の作成

RFC 4122 に従って UUID v4 を作成する

セッションデータの読み取りと書き込み

よくある質問

パスワードのハッシュ化についてはどうですか?

カスタムパスワード要件を実装するにはどうすればよいですか?

セッションで動作する他のライブラリを使用すると問題が発生するのはなぜですか?

他のサイトが私のサイトをフレーム化または埋め込むことができないのはなぜですか?

例外

一般的なアドバイス

貢献する

ライセンス

Cookie のドメインスコープの定義

Cookie のトランスポートセキュリティの構成