# Auth **Authentication for PHP. Simple, lightweight and secure.** Written once, to be used everywhere. Completely framework-agnostic and database-agnostic. ## Why do I need this? * There are [tons](http://www.troyhunt.com/2011/01/whos-who-of-bad-password-practices.html) [of](http://www.jeremytunnell.com/posts/swab-password-policies-and-two-factor-authentication-a-comedy-of-errors) [websites](http://badpasswordpolicies.tumblr.com/) with weak authentication systems. Don’t build such a site. * Re-implementing a new authentication system for every PHP project is *not* a good idea. * Building your own authentication classes piece by piece, and copying it to every project, is *not* recommended, either. * A secure authentication system with an easy-to-use API should be thoroughly designed and planned. * Peer-review for your critical infrastructure is *a must*. ## Requirements * PHP 5.6.0+ * PDO (PHP Data Objects) extension (`pdo`) * MySQL Native Driver (`mysqlnd`) **or** SQLite driver (`sqlite`) * OpenSSL extension (`openssl`) * MySQL 5.5.3+ **or** MariaDB 5.5.23+ **or** SQLite 3.14.1+ **or** other SQL databases that you create the [schema](Database) for ## Installation 1. Include the library via Composer [[?]](https://github.com/delight-im/Knowledge/blob/master/Composer%20(PHP).md): ``` $ composer require delight-im/auth ``` 1. Include the Composer autoloader: ```php require __DIR__ . '/vendor/autoload.php'; ``` 1. Set up a database and create the required tables: * [MySQL](Database/MySQL.sql) * [SQLite](Database/SQLite.sql) ## Upgrading Migrating from an earlier version of this project? See our [upgrade guide](Migration.md) for help. ## Usage * [Creating a new instance](#creating-a-new-instance) * [Registration (sign up)](#registration-sign-up) * [Login (sign in)](#login-sign-in) * [Email verification](#email-verification) * [Keeping the user logged in](#keeping-the-user-logged-in) * [Password reset (“forgot password”)](#password-reset-forgot-password) * [Changing the current user’s password](#changing-the-current-users-password) * [Changing the current user’s email address](#changing-the-current-users-email-address) * [Re-sending confirmation requests](#re-sending-confirmation-requests) * [Logout](#logout) * [Accessing user information](#accessing-user-information) * [Login state](#login-state) * [User ID](#user-id) * [Email address](#email-address) * [Display name](#display-name) * [Checking whether the user was “remembered”](#checking-whether-the-user-was-remembered) * [IP address](#ip-address) * [Additional user information](#additional-user-information) * [Reconfirming the user’s password](#reconfirming-the-users-password) * [Roles (or groups)](#roles-or-groups) * [Checking roles](#checking-roles) * [Available roles](#available-roles) * [Permissions (or access rights, privileges or capabilities)](#permissions-or-access-rights-privileges-or-capabilities) * [Custom role names](#custom-role-names) * [Enabling or disabling password resets](#enabling-or-disabling-password-resets) * [Throttling or rate limiting](#throttling-or-rate-limiting) * [Administration (managing users)](#administration-managing-users) * [Creating new users](#creating-new-users) * [Deleting users](#deleting-users) * [Assigning roles to users](#assigning-roles-to-users) * [Taking roles away from users](#taking-roles-away-from-users) * [Checking roles](#checking-roles-1) * [Utilities](#utilities) * [Creating a random string](#creating-a-random-string) * [Creating a UUID v4 as per RFC 4122](#creating-a-uuid-v4-as-per-rfc-4122) * [Reading and writing session data](#reading-and-writing-session-data) ### Creating a new instance ```php // $db = new \PDO('mysql:dbname=my-database;host=localhost;charset=utf8mb4', 'my-username', 'my-password'); // or // $db = new \PDO('sqlite:../Databases/my-database.sqlite'); // or // $db = new \Delight\Db\PdoDsn('mysql:dbname=my-database;host=localhost;charset=utf8mb4', 'my-username', 'my-password'); // or // $db = new \Delight\Db\PdoDsn('sqlite:../Databases/my-database.sqlite'); $auth = new \Delight\Auth\Auth($db); ``` If you have an open `PDO` connection already, just re-use it. If you do enforce HTTPS on your site, pass `true` as the second parameter to the constructor. This is optional and the default is `false`. Only in the very rare case that you need access to your cookies from JavaScript, pass `true` as the third argument to the constructor. This is optional and the default is `false`. There is almost always a *better* solution than enabling this, however. If your web server is behind a proxy server and `$_SERVER['REMOTE_ADDR']` only contains the proxy’s IP address, you must pass the user’s real IP address to the constructor in the fourth argument. The default is `null`. Should your database tables for this library need a common prefix, e.g. `my_users` instead of `users` (and likewise for the other tables), pass the prefix (e.g. `my_`) as the fifth parameter to the constructor. This is optional and the prefix is empty by default. ### Registration (sign up) ```php try { $userId = $auth->register($_POST['email'], $_POST['password'], $_POST['username'], function ($selector, $token) { // send `$selector` and `$token` to the user (e.g. via email) }); // we have signed up a new user with the ID `$userId` } catch (\Delight\Auth\InvalidEmailException $e) { // invalid email address } catch (\Delight\Auth\InvalidPasswordException $e) { // invalid password } catch (\Delight\Auth\UserAlreadyExistsException $e) { // user already exists } catch (\Delight\Auth\TooManyRequestsException $e) { // too many requests } ``` The username in the third parameter is optional. You can pass `null` there if you don’t want to manage usernames. If you want to enforce unique usernames, on the other hand, simply call `registerWithUniqueUsername` instead of `register`, and be prepared to catch the `DuplicateUsernameException`. For email verification, you should build an URL with the selector and token and send it to the user, e.g.: ```php $url = 'https://www.example.com/verify_email?selector=' . \urlencode($selector) . '&token=' . \urlencode($token); ``` If you don’t want to perform email verification, just omit the last parameter to `Auth#register`. The new user will be active immediately, then. ### Login (sign in) ```php try { $auth->login($_POST['email'], $_POST['password']); // user is logged in } catch (\Delight\Auth\InvalidEmailException $e) { // wrong email address } catch (\Delight\Auth\InvalidPasswordException $e) { // wrong password } catch (\Delight\Auth\EmailNotVerifiedException $e) { // email not verified } catch (\Delight\Auth\TooManyRequestsException $e) { // too many requests } ``` If you want to sign in with usernames on the other hand, either in addition to the login via email address or as a replacement, that’s possible as well. Simply call the method `loginWithUsername` instead of method `login`. Then, instead of catching `InvalidEmailException`, make sure to catch both `UnknownUsernameException` and `AmbiguousUsernameException`. You may also want to read the notes about the uniqueness of usernames in the section that explains how to [sign up new users](#registration-sign-up). ### Email verification Extract the selector and token from the URL that the user clicked on in the verification email. ```php try { $auth->confirmEmail($_GET['selector'], $_GET['token']); // email address has been verified } catch (\Delight\Auth\InvalidSelectorTokenPairException $e) { // invalid token } catch (\Delight\Auth\TokenExpiredException $e) { // token expired } catch (\Delight\Auth\UserAlreadyExistsException $e) { // email address already exists } catch (\Delight\Auth\TooManyRequestsException $e) { // too many requests } ``` If you want the user to be automatically signed in after successful confirmation, just call `confirmEmailAndSignIn` instead of `confirmEmail`. That alternative method also supports [persistent logins](#keeping-the-user-logged-in) via its optional third parameter. ### Keeping the user logged in The third parameter to the `Auth#login` and `Auth#confirmEmailAndSignIn` methods controls whether the login is persistent with a long-lived cookie. With such a persistent login, users may stay authenticated for a long time, even when the browser session has already been closed and the session cookies have expired. Typically, you’ll want to keep the user logged in for weeks or months with this feature, which is known as “remember me” or “keep me logged in”. Many users will find this more convenient, but it may be less secure if they leave their devices unattended. ```php 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); // ... ``` *Without* the persistent login, which is the *default* behavior, a user will only stay logged in until they close their browser, or as long as configured via `session.cookie_lifetime` and `session.gc_maxlifetime` in PHP. Omit the third parameter or set it to `null` to disable the feature. Otherwise, you may ask the user whether they want to enable “remember me”. This is usually done with a checkbox in your user interface. Use the input from that checkbox to decide between `null` and a pre-defined duration in seconds here, e.g. `60 * 60 * 24 * 365.25` for one year. ### Password reset (“forgot password”) ```php try { $auth->forgotPassword($_POST['email'], function ($selector, $token) { // send `$selector` and `$token` to the user (e.g. via email) }); // request has been generated } catch (\Delight\Auth\InvalidEmailException $e) { // invalid email address } catch (\Delight\Auth\EmailNotVerifiedException $e) { // email not verified } catch (\Delight\Auth\ResetDisabledException $e) { // password reset is disabled } catch (\Delight\Auth\TooManyRequestsException $e) { // too many requests } ``` You should build an URL with the selector and token and send it to the user, e.g.: ```php $url = 'https://www.example.com/reset_password?selector=' . \urlencode($selector) . '&token=' . \urlencode($token); ``` As the next step, users will click on the link that they received. Extract the selector and token from the URL. If the selector/token pair is valid, let the user choose a new password: ```php if ($auth->canResetPassword($_POST['selector'], $_POST['token'])) { // put the selector into a `hidden` field (or keep it in the URL) // put the token into a `hidden` field (or keep it in the URL) // ask the user for their new password } ``` Now when you have the new password for the user (and still have the other two pieces of information), you can reset the password: ```php try { $auth->resetPassword($_POST['selector'], $_POST['token'], $_POST['password']); // password has been reset } catch (\Delight\Auth\InvalidSelectorTokenPairException $e) { // invalid token } catch (\Delight\Auth\TokenExpiredException $e) { // token expired } catch (\Delight\Auth\ResetDisabledException $e) { // password reset is disabled } catch (\Delight\Auth\InvalidPasswordException $e) { // invalid password } catch (\Delight\Auth\TooManyRequestsException $e) { // too many requests } ``` ### Changing the current user’s password If a user is currently logged in, they may change their password. ```php try { $auth->changePassword($_POST['oldPassword'], $_POST['newPassword']); // password has been changed } catch (\Delight\Auth\NotLoggedInException $e) { // not logged in } catch (\Delight\Auth\InvalidPasswordException $e) { // invalid password(s) } catch (\Delight\Auth\TooManyRequestsException $e) { // too many requests } ``` Asking the user for their current (and soon *old*) password and requiring it for verification is the recommended way to handle password changes. This is shown above. If you’re sure that you don’t need that confirmation, however, you may call `changePasswordWithoutOldPassword` instead of `changePassword` and drop the first parameter from that method call (which would otherwise contain the old password). In any case, after the user’s password has been changed, you should send an email to their account’s primary email address as an out-of-band notification informing the account owner about this critical change. ### Changing the current user’s email address If a user is currently logged in, they may change their email address. ```php try { if ($auth->reconfirmPassword($_POST['password'])) { $auth->changeEmail($_POST['newEmail'], function ($selector, $token) { // send `$selector` and `$token` to the user (e.g. via email to the *new* address) }); // the change will take effect as soon as the new email address has been confirmed } else { // we can't say if the user is who they claim to be } } catch (\Delight\Auth\InvalidEmailException $e) { // invalid email address } catch (\Delight\Auth\UserAlreadyExistsException $e) { // email address already exists } catch (\Delight\Auth\EmailNotVerifiedException $e) { // account not verified } catch (\Delight\Auth\NotLoggedInException $e) { // not logged in } catch (\Delight\Auth\TooManyRequestsException $e) { // too many requests } ``` For email verification, you should build an URL with the selector and token and send it to the user, e.g.: ```php $url = 'https://www.example.com/verify_email?selector=' . \urlencode($selector) . '&token=' . \urlencode($token); ``` After the request to change the email address has been made, or even better, after the change has been confirmed by the user, you should send an email to their account’s *previous* email address as an out-of-band notification informing the account owner about this critical change. ### Re-sending confirmation requests If an earlier confirmation request could not be delivered to the user, or if the user missed that request, or if they just don’t want to wait any longer, you may re-send an earlier request like this: ```php try { $auth->resendConfirmationForEmail($_POST['email'], function ($selector, $token) { // send `$selector` and `$token` to the user (e.g. via email) }); // the user may now respond to the confirmation request (usually by clicking a link) } catch (\Delight\Auth\ConfirmationRequestNotFound $e) { // no earlier request found that could be re-sent } catch (\Delight\Auth\TooManyRequestsException $e) { // there have been too many requests -- try again later } ``` If you want to specify the user by their ID instead of by their email address, this is possible as well: ```php try { $auth->resendConfirmationForUserId($_POST['userId'], function ($selector, $token) { // send `$selector` and `$token` to the user (e.g. via email) }); // the user may now respond to the confirmation request (usually by clicking a link) } catch (\Delight\Auth\ConfirmationRequestNotFound $e) { // no earlier request found that could be re-sent } catch (\Delight\Auth\TooManyRequestsException $e) { // there have been too many requests -- try again later } ``` Usually, you should build an URL with the selector and token and send it to the user, e.g. as follows: ```php $url = 'https://www.example.com/verify_email?selector=' . \urlencode($selector) . '&token=' . \urlencode($token); ``` ### Logout ```php $auth->logOutButKeepSession(); // or $auth->logout(); // user has been signed out ``` ### Accessing user information #### Login state ```php if ($auth->isLoggedIn()) { // user is signed in } else { // user is *not* signed in yet } ``` A shorthand/alias for this method is `$auth->check()`. #### User ID ```php $id = $auth->getUserId(); ``` If the user is not currently signed in, this returns `null`. A shorthand/alias for this method is `$auth->id()`. #### Email address ```php $email = $auth->getEmail(); ``` If the user is not currently signed in, this returns `null`. #### Display name ```php $email = $auth->getUsername(); ``` Remember that usernames are optional and there is only a username if you supplied it during registration. If the user is not currently signed in, this returns `null`. #### Status information ```php if ($auth->isNormal()) { // user is in default state } if ($auth->isArchived()) { // user has been archived } if ($auth->isBanned()) { // user has been banned } if ($auth->isLocked()) { // user has been locked } if ($auth->isPendingReview()) { // user is pending review } if ($auth->isSuspended()) { // user has been suspended } ``` #### Checking whether the user was “remembered” ```php if ($auth->isRemembered()) { // user did not sign in but was logged in through their long-lived cookie } else { // user signed in manually } ``` If the user is not currently signed in, this returns `null`. #### IP address ```php $ip = $auth->getIpAddress(); ``` #### Additional user information In order to preserve this library’s suitability for all purposes as well as its full re-usability, it doesn’t come with additional bundled columns for user information. But you don’t have to do without additional user information, of course: Here’s how to use this library with your own tables for custom user information in a maintainable and re-usable way: 1. Add any number of custom database tables where you store custom user information, e.g. a table named `profiles`. 1. Whenever you call the `register` method (which returns the new user’s ID), add your own logic afterwards that fills your custom database tables. 1. If you need the custom user information only rarely, you may just retrieve it as needed. If you need it more frequently, however, you’d probably want to have it in your session data. The following method is how you can load and access your data in a reliable way: ```php 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']; } ``` ### Reconfirming the user’s password Whenever you want to confirm the user’s identity again, e.g. before the user is allowed to perform some “dangerous” action, you should verify their password again to confirm that they actually are who they claim to be. For example, when a user has been remembered by a long-lived cookie and thus `Auth#isRemembered` returns `true`, this means that the user probably has not entered their password for quite some time anymore. You may want to reconfirm their password in that case. ```php try { if ($auth->reconfirmPassword($_POST['password'])) { // the user really seems to be who they claim to be } else { // we can't say if the user is who they claim to be } } catch (\Delight\Auth\NotLoggedInException $e) { // the user is not signed in } catch (\Delight\Auth\TooManyRequestsException $e) { // too many requests } ``` ### Roles (or groups) Every user can have any number of roles, which you can use to implement authorization and to refine your access controls. Users may have no role at all (which they do by default), exactly one role, or any arbitrary combination of roles. #### Checking roles ```php if ($auth->hasRole(\Delight\Auth\Role::SUPER_MODERATOR)) { // the user is a super moderator } // or if ($auth->hasAnyRole(\Delight\Auth\Role::DEVELOPER, \Delight\Auth\Role::MANAGER)) { // the user is either a developer, or a manager, or both } // or if ($auth->hasAllRoles(\Delight\Auth\Role::DEVELOPER, \Delight\Auth\Role::MANAGER)) { // the user is both a developer and a manager } ``` While the method `hasRole` takes exactly one role as its argument, the two methods `hasAnyRole` and `hasAllRoles` can take any number of roles that you would like to check for. #### Available roles ```php \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; ``` You can use any of these roles and ignore those that you don’t need. #### Permissions (or access rights, privileges or capabilities) The permissions of each user are encoded in the way that role requirements are specified throughout your code base. If those requirements are evaluated with a specific user’s set of roles, implicitly checked permissions are the result. For larger projects, it is often recommended to maintain the definition of permissions in a single place. You then don’t check for *roles* in your business logic, but you check for *individual permissions*. You could implement that concept as follows: ```php 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($app->auth())) { // the user can edit articles here } // ... if (canEditArticle($app->auth())) { // ... and here } // ... if (canEditArticle($app->auth())) { // ... and here } ``` As you can see, the permission of whether a certain user can edit an article is stored at a central location. This implementation has two major advantages: If you *want to know* which users can edit articles, you don’t have to check your business logic in various places, but you only have to look where the specific permission is defined. And if you want to *change* who can edit an article, you only have to do this in one single place as well, not throughout your whole code base. But this also comes with slightly more overhead when implementing the access restrictions for the first time, which may or may not be worth it for your project. #### Custom role names If the names of the included roles don’t work for you, you can alias any number of roles using your own identifiers, e.g. like this: ```php namespace My\Namespace; final class MyRole { const CUSTOMER_SERVICE_AGENT = \Delight\Auth\Role::REVIEWER; const FINANCIAL_DIRECTOR = \Delight\Auth\Role::COORDINATOR; private function __construct() {} } ``` The example above would allow you to use ```php \My\Namespace\MyRole::CUSTOMER_SERVICE_AGENT; // and \My\Namespace\MyRole::FINANCIAL_DIRECTOR; ``` instead of ```php \Delight\Auth\Role::REVIEWER; // and \Delight\Auth\Role::COORDINATOR; ``` Just remember *not* to alias a *single* included role to *multiple* roles with custom names. ### Enabling or disabling password resets While password resets via email are a convenient feature that most users find helpful from time to time, the availability of this feature implies that accounts on your service are only ever as secure as the user’s associated email account. You may provide security-conscious (and experienced) users with the possibility to disable password resets for their accounts (and to enable them again later) for enhanced security: ```php try { if ($auth->reconfirmPassword($_POST['password'])) { $auth->setPasswordResetEnabled($_POST['enabled'] == 1); // the setting has been changed } else { // we can't say if the user is who they claim to be } } catch (\Delight\Auth\NotLoggedInException $e) { // the user is not signed in } catch (\Delight\Auth\TooManyRequestsException $e) { // too many requests } ``` In order to check the current value of this setting, use the return value from ```php $auth->isPasswordResetEnabled(); ``` for the correct default option in your user interface. You don’t need to check this value for restrictions of the feature, which are enforced automatically. ### Throttling or rate limiting All methods provided by this library are *automatically* protected against excessive numbers of requests from clients. If you would like to throttle or rate limit *external* features or methods as well, e.g. those in your own code, you can make use of the built-in helper method for throttling and rate limiting: ```php try { // throttle the specified resource or feature to *3* requests per *60* seconds $auth->throttle([ 'my-resource-name' ], 3, 60); // do something with the resource or feature } catch (\Delight\Auth\TooManyRequestsException $e) { // operation cancelled \http_response_code(429); exit; } ``` If the protection of the resource or feature should additionally depend on another attribute, e.g. to track something separately per IP address, just add more data to the resource description, such as: ```php [ 'my-resource-name', $_SERVER['REMOTE_ADDR'] ] // instead of // [ 'my-resource-name' ] ``` Allowing short bursts of activity during peak demand is possible by specifying a burst factor as the fourth argument. A value of `5`, for example, would permit temporary bursts of fivefold activity, compared to the generally accepted level. In some cases, you may just want to *simulate* the throttling or rate limiting. This lets you check whether an action would be permitted without actually modifying the activity tracker. To do so, simply pass `true` as the fifth argument. ### Administration (managing users) The administrative interface is available via `$auth->admin()`. You can call various method on this interface, as documented below. Do not forget to implement secure access control before exposing access to this interface. For example, you may provide access to this interface to logged in users with the administrator role only, or use the interface in private scripts only. #### Creating new users ```php try { $userId = $auth->admin()->createUser($_POST['email'], $_POST['password'], $_POST['username']); // we have signed up a new user with the ID `$userId` } catch (\Delight\Auth\InvalidEmailException $e) { // invalid email address } catch (\Delight\Auth\InvalidPasswordException $e) { // invalid password } catch (\Delight\Auth\UserAlreadyExistsException $e) { // user already exists } ``` The username in the third parameter is optional. You can pass `null` there if you don’t want to manage usernames. If you want to enforce unique usernames, on the other hand, simply call `createUserWithUniqueUsername` instead of `createUser`, and be prepared to catch the `DuplicateUsernameException`. #### Deleting users Deleting users by their ID: ```php try { $auth->admin()->deleteUserById($_POST['id']); } catch (\Delight\Auth\UnknownIdException $e) { // unknown ID } ``` Deleting users by their email address: ```php try { $auth->admin()->deleteUserByEmail($_POST['email']); } catch (\Delight\Auth\InvalidEmailException $e) { // unknown email address } ``` Deleting users by their username: ```php try { $auth->admin()->deleteUserByUsername($_POST['username']); } catch (\Delight\Auth\UnknownUsernameException $e) { // unknown username } catch (\Delight\Auth\AmbiguousUsernameException $e) { // ambiguous username } ``` #### Assigning roles to users ```php try { $auth->admin()->addRoleForUserById($userId, \Delight\Auth\Role::ADMIN); } catch (\Delight\Auth\UnknownIdException $e) { // unknown user ID } // or try { $auth->admin()->addRoleForUserByEmail($userEmail, \Delight\Auth\Role::ADMIN); } catch (\Delight\Auth\InvalidEmailException $e) { // unknown email address } // or try { $auth->admin()->addRoleForUserByUsername($username, \Delight\Auth\Role::ADMIN); } catch (\Delight\Auth\UnknownUsernameException $e) { // unknown username } catch (\Delight\Auth\AmbiguousUsernameException $e) { // ambiguous username } ``` #### Taking roles away from users ```php try { $auth->admin()->removeRoleForUserById($userId, \Delight\Auth\Role::ADMIN); } catch (\Delight\Auth\UnknownIdException $e) { // unknown user ID } // or try { $auth->admin()->removeRoleForUserByEmail($userEmail, \Delight\Auth\Role::ADMIN); } catch (\Delight\Auth\InvalidEmailException $e) { // unknown email address } // or try { $auth->admin()->removeRoleForUserByUsername($username, \Delight\Auth\Role::ADMIN); } catch (\Delight\Auth\UnknownUsernameException $e) { // unknown username } catch (\Delight\Auth\AmbiguousUsernameException $e) { // ambiguous username } ``` #### Checking roles ```php try { if ($auth->admin()->doesUserHaveRole($userId, \Delight\Auth\Role::ADMIN)) { // the specified user is an administrator } else { // the specified user is *not* an administrator } } catch (\Delight\Auth\UnknownIdException $e) { // unknown user ID } ``` ### Utilities #### Creating a random string ```php $length = 24; $randomStr = \Delight\Auth\Auth::createRandomString($length); ``` #### Creating a UUID v4 as per RFC 4122 ```php $uuid = \Delight\Auth\Auth::createUuid(); ``` ### Reading and writing session data For detailed information on how to read and write session data conveniently, please refer to [the documentation of the session library](https://github.com/delight-im/PHP-Cookie#reading-and-writing-session-data), which is included by default. ## Frequently asked questions ### What about password hashing? Any password or authentication token is automatically hashed using the [“bcrypt”](https://en.wikipedia.org/wiki/Bcrypt) function, which is based on the [“Blowfish” cipher](https://en.wikipedia.org/wiki/Blowfish_(cipher)) and (still) considered one of the strongest password hash functions today. “bcrypt” is used with 1,024 iterations, i.e. a “cost” factor of 10. A random [“salt”](https://en.wikipedia.org/wiki/Salt_(cryptography)) is applied automatically as well. You can verify this configuration by looking at the hashes in your database table `users`. If the above is true with your setup, all password hashes in your `users` table should start with the prefix `$2$10$`, `$2a$10$` or `$2y$10$`. When new algorithms (such as [Argon2](https://en.wikipedia.org/wiki/Argon2)) may be introduced in the future, this library will automatically take care of “upgrading” your existing password hashes whenever a user signs in or changes their password. ### How can I implement custom password requirements? Enforcing a minimum length for passwords is usually a good idea. Apart from that, you may want to look up whether a potential password is in some blacklist, which you could manage in a database or in a file, in order to prevent dictionary words or commonly used passwords from being used in your application. To allow for maximum flexibility and ease of use, this library has been designed so that it does *not* contain any further checks for password requirements itself, but instead allows you to wrap your own checks around the relevant calls to library methods. Example: ```php 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); } ``` ### Why are there problems when using other libraries that work with sessions? You might try loading this library first, and creating the `Auth` instance first, *before* loading the other libraries. Apart from that, there’s probably not much we can do here. ### Why are other sites not able to frame or embed my site? If you want to let others include your site in a ``, `