PHP Auth
1.0.0
Autenticação para PHP. Simples, leve e seguro.
Escrito uma vez, para ser usado em qualquer lugar.
Completamente independente de estrutura e banco de dados.
pdo )mysqlnd ) ou driver PostgreSQL ( pgsql ) ou driver SQLite ( sqlite )openssl )Incluir a biblioteca via Composer [?]:
$ composer require delight-im/auth
Inclua o autoloader do Composer:
require __DIR__ . ' /vendor/autoload.php ' ;Configure um banco de dados e crie as tabelas necessárias:
Migrando de uma versão anterior deste projeto? Consulte nosso guia de atualização para obter ajuda.
// $ 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 ); Se você já possui uma conexão PDO aberta, basta reutilizá-la. O usuário do banco de dados (por exemplo, my-username ) precisa de pelo menos os privilégios SELECT , INSERT , UPDATE e DELETE para as tabelas usadas por esta biblioteca (ou seu banco de dados pai).
Se o seu servidor web estiver atrás de um servidor proxy e $_SERVER['REMOTE_ADDR'] contém apenas o endereço IP do proxy, você deve passar o endereço IP real do usuário para o construtor no segundo argumento, que é denominado $ipAddress . O padrão é o endereço IP remoto normal recebido pelo PHP.
Caso suas tabelas de banco de dados para esta biblioteca precisem de um prefixo comum, por exemplo, my_users em vez de users (e da mesma forma para as outras tabelas), passe o prefixo (por exemplo, my_ ) como o terceiro parâmetro para o construtor, que é denominado $dbTablePrefix . Isso é opcional e o prefixo está vazio por padrão.
Durante o desenvolvimento, você pode querer desabilitar a limitação ou otimização de solicitações executada por esta biblioteca. Para fazer isso, passe false para o construtor como o quarto argumento, chamado $throttling . O recurso está habilitado por padrão.
Durante a duração de uma sessão, alguns dados do usuário podem ser alterados remotamente, seja por um cliente em outra sessão ou por um administrador. Isso significa que essas informações devem ser ressincronizadas regularmente com sua fonte oficial no banco de dados, o que esta biblioteca faz automaticamente. Por padrão, isso acontece a cada cinco minutos. Se você quiser alterar esse intervalo, passe um intervalo personalizado em segundos para o construtor como o quinto argumento, chamado $sessionResyncInterval .
Se todas as suas tabelas de banco de dados precisarem de um nome de banco de dados comum, nome de esquema ou outro qualificador que deva ser especificado explicitamente, você poderá opcionalmente passar esse qualificador para o construtor como o sexto parâmetro, chamado $dbSchema .
Se você também quiser usar uma instância PdoDatabase (por exemplo, $db ) de forma independente, consulte a documentação da biblioteca do banco de dados.
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 ' );
} Nota: A função de retorno de chamada anônima é um fechamento. Assim, além de seus próprios parâmetros, apenas superglobais como $_GET , $_POST , $_COOKIE e $_SERVER estão disponíveis dentro. Para qualquer outra variável do escopo pai, você precisa disponibilizar explicitamente uma cópia adicionando uma cláusula use após a lista de parâmetros.
O nome de usuário no terceiro parâmetro é opcional. Você pode passar null lá se não quiser gerenciar nomes de usuários.
Por outro lado, se você deseja impor nomes de usuário exclusivos, basta chamar em registerWithUniqueUsername vez de register e estar preparado para capturar DuplicateUsernameException .
Nota: Ao aceitar e gerenciar nomes de usuários, você pode querer excluir caracteres de controle não imprimíveis e certos caracteres especiais imprimíveis, como na classe de caracteres [x00-x1fx7f/:\] . Para fazer isso, você pode agrupar a chamada para Auth#register ou Auth#registerWithUniqueUsername dentro de uma ramificação condicional, por exemplo, aceitando nomes de usuário apenas quando a seguinte condição for satisfeita:
if ( preg_match ( ' /[x00-x1fx7f/: \\ ]/ ' , $ username ) === 0 ) {
// ...
}Para verificação de e-mail, você deve construir uma URL com o seletor e o token e enviá-la ao usuário, por exemplo:
$ url = ' https://www.example.com/verify_email?selector= ' . urlencode ( $ selector ) . ' &token= ' . urlencode ( $ token ); Se você não quiser realizar a verificação de e-mail, basta omitir o último parâmetro de Auth#register , ou seja, a função anônima ou fechamento. O novo usuário ficará ativo imediatamente.
Precisa armazenar informações adicionais do usuário? Leia aqui.
Nota: Ao enviar um e-mail ao usuário, observe que o nome de usuário (opcional), neste momento, ainda não foi confirmado como aceitável para o proprietário do (novo) endereço de e-mail. Pode conter linguagem ofensiva ou enganosa escolhida por alguém que não é realmente o proprietário do endereço.
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 ' );
} Por outro lado, se você quiser fazer login com nomes de usuário, seja além do login via endereço de e-mail ou como substituto, isso também é possível. Basta chamar o método loginWithUsername em vez do método login . Então, em vez de capturar InvalidEmailException , certifique-se de capturar UnknownUsernameException e AmbiguousUsernameException . Você também pode ler as notas sobre a exclusividade dos nomes de usuário na seção que explica como inscrever novos usuários.
Extraia o seletor e o token do URL em que o usuário clicou no e-mail de verificação.
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 ' );
} Se você deseja que o usuário faça login automaticamente após a confirmação bem-sucedida, basta chamar confirmEmailAndSignIn em vez de confirmEmail . Esse método alternativo também oferece suporte a logins persistentes por meio de seu terceiro parâmetro opcional.
Em caso de sucesso, os dois métodos confirmEmail e confirmEmailAndSignIn retornam uma matriz com o novo endereço de e-mail do usuário, que acabou de ser verificado, no índice um. Se a confirmação for para uma alteração de endereço em vez de uma simples verificação de endereço, o endereço de e-mail antigo do usuário será incluído na matriz no índice zero.
O terceiro parâmetro para os métodos Auth#login e Auth#confirmEmailAndSignIn controla se o login é persistente com um cookie de longa duração. Com um login tão persistente, os usuários podem permanecer autenticados por um longo período, mesmo quando a sessão do navegador já foi encerrada e os cookies da sessão expiraram. Normalmente, você desejará manter o usuário conectado por semanas ou meses com esse recurso, que é conhecido como “lembrar de mim” ou “manter-me conectado”. Muitos usuários acharão isso mais conveniente, mas pode ser menos seguro se deixarem seus dispositivos sem supervisão.
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 );
// . . . Sem o login persistente, que é o comportamento padrão , o usuário só permanecerá logado até fechar o navegador, ou enquanto configurado via session.cookie_lifetime e session.gc_maxlifetime no PHP.
Omita o terceiro parâmetro ou defina-o como null para desabilitar o recurso. Caso contrário, você pode perguntar ao usuário se ele deseja ativar “lembrar de mim”. Isso geralmente é feito com uma caixa de seleção na interface do usuário. Use a entrada dessa caixa de seleção para decidir entre null e uma duração predefinida em segundos aqui, por exemplo, 60 * 60 * 24 * 365.25 por um ano.
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 ' );
} Nota: A função de retorno de chamada anônima é um encerramento. Assim, além de seus próprios parâmetros, apenas superglobais como $_GET , $_POST , $_COOKIE e $_SERVER estão disponíveis dentro. Para qualquer outra variável do escopo pai, você precisa disponibilizar explicitamente uma cópia adicionando uma cláusula use após a lista de parâmetros.
Você deve construir uma URL com o seletor e o token e enviá-la ao usuário, por exemplo:
$ url = ' https://www.example.com/reset_password?selector= ' . urlencode ( $ selector ) . ' &token= ' . urlencode ( $ token ); Se o tempo de vida padrão das solicitações de redefinição de senha não funcionar para você, você poderá usar o terceiro parâmetro de Auth#forgotPassword para especificar um intervalo personalizado em segundos após o qual as solicitações devem expirar.
Na próxima etapa, os usuários clicarão no link que receberam. Extraia o seletor e o token do URL.
Se o par seletor/token for válido, deixe o usuário escolher uma nova senha:
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 ' );
}Alternativamente, se você não precisar de nenhuma mensagem de erro, mas quiser apenas verificar a validade, poderá usar a versão um pouco mais simples:
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 ' ;
}Agora, quando você tiver a nova senha do usuário (e ainda tiver as outras duas informações), poderá redefinir a senha:
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 ' );
} Você deseja que o respectivo usuário faça login automaticamente quando a redefinição de senha for bem-sucedida? Basta usar Auth#resetPasswordAndSignIn em vez de Auth#resetPassword para efetuar login do usuário imediatamente.
Se você precisar do ID ou endereço de e-mail do usuário, por exemplo, para enviar uma notificação de que sua senha foi redefinida com sucesso, basta usar o valor de retorno de Auth#resetPassword , que é uma matriz contendo duas entradas chamadas id e email .
Se um usuário estiver conectado no momento, ele poderá alterar sua senha.
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 ' );
}Pedir ao usuário sua senha atual (e em breve antiga ) e solicitá-la para verificação é a maneira recomendada de lidar com alterações de senha. Isso é mostrado acima.
Se tiver certeza de que não precisa dessa confirmação, no entanto, você pode chamar changePasswordWithoutOldPassword em vez de changePassword e descartar o primeiro parâmetro dessa chamada de método (que de outra forma conteria a senha antiga).
De qualquer forma, após a alteração da senha do usuário, você deverá enviar um e-mail para o endereço de e-mail principal da conta como uma notificação fora de banda informando o proprietário da conta sobre essa alteração crítica.
Se um usuário estiver conectado no momento, ele poderá alterar seu endereço de e-mail.
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 ' );
} Nota: A função de retorno de chamada anônima é um encerramento. Assim, além de seus próprios parâmetros, apenas superglobais como $_GET , $_POST , $_COOKIE e $_SERVER estão disponíveis dentro. Para qualquer outra variável do escopo pai, você precisa disponibilizar explicitamente uma cópia adicionando uma cláusula use após a lista de parâmetros.
Para verificação de e-mail, você deve construir uma URL com o seletor e o token e enviá-la ao usuário, por exemplo:
$ url = ' https://www.example.com/verify_email?selector= ' . urlencode ( $ selector ) . ' &token= ' . urlencode ( $ token );Nota: Ao enviar um e-mail ao usuário, observe que o nome de usuário (opcional), neste momento, ainda não foi confirmado como aceitável para o proprietário do (novo) endereço de e-mail. Pode conter linguagem ofensiva ou enganosa escolhida por alguém que não é realmente o proprietário do endereço.
Após a solicitação de alteração do endereço de e-mail ter sido feita, ou melhor ainda, após a alteração ter sido confirmada pelo usuário, você deverá enviar um e-mail para o endereço de e-mail anterior da conta como uma notificação fora de banda informando o proprietário da conta sobre esta mudança crítica.
Observação: as alterações no endereço de e-mail de um usuário entram em vigor imediatamente na sessão local, conforme esperado. Em outras sessões (por exemplo, em outros dispositivos), as alterações podem levar até cinco minutos para entrar em vigor. Isso aumenta o desempenho e geralmente não representa nenhum problema. Se você quiser alterar esse comportamento, simplesmente diminua (ou talvez aumente) o valor que você passa para o construtor Auth como o argumento chamado $sessionResyncInterval .
Se uma solicitação de confirmação anterior não puder ser entregue ao usuário, ou se o usuário perdeu essa solicitação, ou se simplesmente não quiser esperar mais, você poderá reenviar uma solicitação anterior como esta:
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 ' );
}Se você quiser especificar o usuário pelo ID em vez do endereço de e-mail, isso também é possível:
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 ' );
} Nota: A função de retorno de chamada anônima é um fechamento. Assim, além de seus próprios parâmetros, apenas superglobais como $_GET , $_POST , $_COOKIE e $_SERVER estão disponíveis dentro. Para qualquer outra variável do escopo pai, você precisa disponibilizar explicitamente uma cópia interna, adicionando uma cláusula use após a lista de parâmetros.
Normalmente, você deve construir uma URL com o seletor e o token e enviá-la ao usuário, por exemplo:
$ url = ' https://www.example.com/verify_email?selector= ' . urlencode ( $ selector ) . ' &token= ' . urlencode ( $ token );Nota: Ao enviar um e-mail ao usuário, observe que o nome de usuário (opcional), neste momento, ainda não foi confirmado como aceitável para o proprietário do (novo) endereço de e-mail. Pode conter linguagem ofensiva ou enganosa escolhida por alguém que não é realmente o proprietário do endereço.
$ 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 ' );
}Além disso, se você também armazenar informações personalizadas na sessão e quiser que essas informações sejam excluídas, poderá destruir a sessão inteira chamando um segundo método:
$ auth -> destroySession (); Nota: Os logouts globais entram em vigor na sessão local imediatamente, conforme esperado. Em outras sessões (por exemplo, em outros dispositivos), as alterações podem levar até cinco minutos para entrar em vigor. Isso aumenta o desempenho e geralmente não representa nenhum problema. Se você quiser alterar esse comportamento, simplesmente diminua (ou talvez aumente) o valor que você passa para o construtor Auth como o argumento denominado $sessionResyncInterval .
if ( $ auth -> isLoggedIn ()) {
echo ' User is signed in ' ;
}
else {
echo ' User is not signed in yet ' ;
} Uma abreviatura/alias para este método é $auth->check() .
$ id = $ auth -> getUserId (); Se o usuário não estiver conectado no momento, isso retornará null .
Uma abreviatura/alias para este método é $auth->id() .
$ email = $ auth -> getEmail (); Se o usuário não estiver conectado no momento, isso retornará null .
$ username = $ auth -> getUsername ();Lembre-se de que os nomes de usuário são opcionais e só existe um nome de usuário se você o tiver fornecido durante o registro.
Se o usuário não estiver conectado no momento, isso retornará 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 ' ;
} Se o usuário não estiver conectado no momento, isso retornará null .
$ ip = $ auth -> getIpAddress ();Para preservar a adequação desta biblioteca para todos os fins, bem como sua total reutilização, ela não vem com colunas adicionais agrupadas para informações do usuário. Mas você não precisa ficar sem informações adicionais do usuário, é claro:
Veja como usar esta biblioteca com suas próprias tabelas para obter informações personalizadas do usuário de maneira sustentável e reutilizável:
Adicione qualquer número de tabelas de banco de dados personalizadas onde você armazena informações personalizadas do usuário, por exemplo, uma tabela chamada profiles .
Sempre que você chamar o método register (que retorna o ID do novo usuário), adicione posteriormente sua própria lógica que preencha suas tabelas de banco de dados personalizadas.
Se você precisar das informações personalizadas do usuário raramente, poderá recuperá-las conforme necessário. No entanto, se você precisar dele com mais frequência, provavelmente desejará tê-lo nos dados da sua sessão. O método a seguir mostra como você pode carregar e acessar seus dados de maneira confiável:
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 ' ];
}Sempre que você quiser confirmar a identidade do usuário novamente, por exemplo, antes que o usuário possa realizar alguma ação “perigosa”, você deverá verificar sua senha novamente para confirmar se ele realmente é quem afirma ser.
Por exemplo, quando um usuário foi lembrado por um cookie de longa duração e, portanto, Auth#isRemembered retorna true , isso significa que o usuário provavelmente não digita sua senha há algum tempo. Você pode reconfirmar a senha nesse caso.
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 ' );
}Cada usuário pode ter qualquer número de funções, que você pode usar para implementar autorização e refinar seus controles de acesso.
Os usuários podem não ter nenhuma função (o que fazem por padrão), ter exatamente uma função ou qualquer combinação arbitrária de funções.
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 ' ;
} Embora o método hasRole assuma exatamente uma função como argumento, os dois métodos hasAnyRole e hasAllRoles podem assumir qualquer número de funções que você gostaria de verificar.
Como alternativa, você pode obter uma lista de todas as funções atribuídas ao usuário:
$ 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 ;Você pode usar qualquer uma dessas funções e ignorar aquelas que não precisa. A lista acima também pode ser recuperada programaticamente, em um dos três formatos:
Delight Auth Role:: getMap ();
// or
Delight Auth Role:: getNames ();
// or
Delight Auth Role:: getValues ();As permissões de cada usuário são codificadas da maneira que os requisitos de função são especificados em toda a sua base de código. Se esses requisitos forem avaliados com um conjunto de funções de usuário específico, o resultado serão permissões verificadas implicitamente.
Para projetos maiores, muitas vezes é recomendado manter a definição de permissões em um único local. Dessa forma, você não verifica funções em sua lógica de negócios, mas verifica permissões individuais . Você poderia implementar esse conceito da seguinte maneira:
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 ' ;
}Como você pode ver, a permissão para um determinado usuário editar um artigo é armazenada em um local central. Esta implementação tem duas vantagens principais:
Se você quiser saber quais usuários podem editar artigos, você não precisa verificar sua lógica de negócios em vários lugares, mas apenas procurar onde a permissão específica está definida. E se você quiser alterar quem pode editar um artigo, você só precisa fazer isso em um único lugar, e não em toda a sua base de código.
Mas isso também acarreta um pouco mais de sobrecarga ao implementar as restrições de acesso pela primeira vez, o que pode ou não valer a pena para o seu projeto.
Se os nomes das funções incluídas não funcionarem para você, você pode criar um alias para qualquer número de funções usando seus próprios identificadores, por exemplo, assim:
namespace My Namespace ;
final class MyRole {
const CUSTOMER_SERVICE_AGENT = Delight Auth Role:: REVIEWER ;
const FINANCIAL_DIRECTOR = Delight Auth Role:: COORDINATOR ;
private function __construct () {}
}O exemplo acima permitiria que você usasse
My Namespace MyRole:: CUSTOMER_SERVICE_AGENT ;
// and
My Namespace MyRole:: FINANCIAL_DIRECTOR ;em vez de
Delight Auth Role:: REVIEWER ;
// and
Delight Auth Role:: COORDINATOR ;Apenas lembre-se de não usar o alias de uma única função incluída para várias funções com nomes personalizados.
Embora a redefinição de senha por e-mail seja um recurso conveniente que a maioria dos usuários considera útil de tempos em tempos, a disponibilidade desse recurso implica que as contas do seu serviço sejam tão seguras quanto a conta de e-mail associada do usuário.
Você pode fornecer aos usuários preocupados com a segurança (e experientes) a possibilidade de desativar as redefinições de senha para suas contas (e ativá-las novamente mais tarde) para aumentar a segurança:
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 ' );
}Para verificar o valor atual desta configuração, use o valor de retorno de
$ auth -> isPasswordResetEnabled ();para obter a opção padrão correta em sua interface de usuário. Você não precisa verificar esse valor para restrições do recurso, que são aplicadas automaticamente.
Todos os métodos fornecidos por esta biblioteca são automaticamente protegidos contra um número excessivo de solicitações de clientes. Se necessário, você pode desabilitar (temporariamente) essa proteção usando o parâmetro $throttling passado ao construtor.
Se você também quiser limitar ou limitar a taxa de recursos ou métodos externos , por exemplo, aqueles em seu próprio código, você pode usar o método auxiliar integrado para limitação e limitação de taxa:
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 ;
}Se a proteção do recurso ou funcionalidade depender adicionalmente de outro atributo, por exemplo, para rastrear algo separadamente por endereço IP, basta adicionar mais dados à descrição do recurso, como:
[ ' my-resource-name ' , $ _SERVER [ ' REMOTE_ADDR ' ] ]
// instead of
// [ ' my-resource-name' ] Permitir pequenos surtos de atividade durante picos de demanda é possível especificando um fator de pico como o quarto argumento. Um valor de 5 , por exemplo, permitiria explosões temporárias de atividade quíntupla, em comparação com o nível geralmente aceito.
Em alguns casos, você pode querer apenas simular a limitação ou limitação de taxa. Isso permite verificar se uma ação seria permitida sem realmente modificar o rastreador de atividades. Para fazer isso, simplesmente passe true como o quinto argumento.
Observação: quando você desativa a limitação na instância (usando o parâmetro $throttling passado ao construtor), isso desativa a proteção interna automática e o efeito de quaisquer chamadas para Auth#throttle no código do seu próprio aplicativo – a menos que você também defina o parâmetro opcional $force para true em chamadas Auth#throttle específicas.
A interface administrativa está disponível via $auth->admin() . Você pode chamar vários métodos nesta interface, conforme documentado abaixo.
Não se esqueça de implementar o controle de acesso seguro antes de expor o acesso a esta interface. Por exemplo, você pode fornecer acesso a essa interface apenas para usuários conectados com função de administrador ou usar a interface apenas em scripts privados.
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 ' );
} O nome de usuário no terceiro parâmetro é opcional. Você pode passar null lá se não quiser gerenciar nomes de usuários.
Por outro lado, se você deseja impor nomes de usuário exclusivos, basta chamar createUserWithUniqueUsername em vez de createUser e estar preparado para capturar DuplicateUsernameException .
Excluindo usuários pelo ID:
try {
$ auth -> admin ()-> deleteUserById ( $ _POST [ ' id ' ]);
}
catch ( Delight Auth UnknownIdException $ e ) {
die ( ' Unknown ID ' );
}Excluindo usuários pelo endereço de e-mail:
try {
$ auth -> admin ()-> deleteUserByEmail ( $ _POST [ ' email ' ]);
}
catch ( Delight Auth InvalidEmailException $ e ) {
die ( ' Unknown email address ' );
}Excluindo usuários pelo nome de usuário:
try {
$ auth -> admin ()-> deleteUserByUsername ( $ _POST [ ' username ' ]);
}
catch ( Delight Auth UnknownUsernameException $ e ) {
die ( ' Unknown username ' );
}
catch ( Delight Auth AmbiguousUsernameException $ e ) {
die ( ' Ambiguous username ' );
}Ao buscar uma lista de todos os usuários, os requisitos variam muito entre projetos e casos de uso, e a customização é comum. Por exemplo, você pode querer buscar colunas diferentes, unir tabelas relacionadas, filtrar por determinados critérios, alterar a forma como os resultados são classificados (em direções variadas) e limitar o número de resultados (enquanto fornece um deslocamento).
É por isso que é mais fácil usar uma única consulta SQL personalizada. Comece com o seguinte:
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 ' );
} Observação: as alterações no conjunto de funções de um usuário podem levar até cinco minutos para entrar em vigor. Isso aumenta o desempenho e geralmente não representa nenhum problema. Se você quiser alterar esse comportamento, simplesmente diminua (ou talvez aumente) o valor que você passa para o construtor Auth como o argumento denominado $sessionResyncInterval .
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 ' );
} Observação: as alterações no conjunto de funções de um usuário podem levar até cinco minutos para entrar em vigor. Isso aumenta o desempenho e geralmente não representa nenhum problema. Se você quiser alterar esse comportamento, simplesmente diminua (ou talvez aumente) o valor que você passa para o construtor Auth como o argumento chamado $sessionResyncInterval .
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 ' );
}Como alternativa, você pode obter uma lista de todas as funções atribuídas ao usuário:
$ 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 ' );
}Esta biblioteca usa dois cookies para manter o estado do cliente: O primeiro, cujo nome você pode recuperar usando
session_name ();é o cookie de sessão geral (obrigatório). O segundo cookie (opcional) é usado apenas para logins persistentes e seu nome pode ser recuperado da seguinte forma:
Delight Auth Auth:: createRememberCookieName ();Você pode renomear o cookie de sessão usado por esta biblioteca através de um dos seguintes meios, em ordem de recomendação:
Na configuração do PHP ( php.ini ), encontre a linha com a diretiva session.name e altere seu valor para algo como session_v1 , como em:
session.name = session_v1
O mais cedo possível em sua aplicação e antes de criar a instância Auth , chame ini_set para alterar session.name para algo como session_v1 , como em:
ini_set ( ' session.name ' , ' session_v1 ' ); Para que isso funcione, session.auto_start deve ser definido como 0 na configuração do PHP ( php.ini ).
O mais cedo possível em seu aplicativo e antes de criar a instância Auth , chame session_name com um argumento como session_v1 , como em:
session_name ( ' session_v1 ' ); Para que isso funcione, session.auto_start deve ser definido como 0 na configuração do PHP ( php.ini ).
O nome do cookie para logins persistentes também mudará – automaticamente – após a alteração do nome do cookie de sessão.
O atributo domain de um cookie controla para qual domínio (e quais subdomínios) o cookie será válido e, portanto, onde a sessão do usuário e o estado de autenticação estarão disponíveis.
O padrão recomendado é uma string vazia, o que significa que o cookie só será válido para o host atual exato , excluindo quaisquer subdomínios que possam existir. Você só deve usar um valor diferente se precisar compartilhar cookies entre subdomínios diferentes. Freqüentemente, você desejará compartilhar cookies entre o domínio simples e o subdomínio www , mas também poderá querer compartilhá-los entre qualquer outro conjunto de subdomínios.
Qualquer que seja o conjunto de subdomínios escolhido, você deve definir o atributo do cookie para o nome de domínio mais específico que ainda inclua todos os subdomínios necessários. Por exemplo, para compartilhar cookies entre example.com e www.example.com , você definiria o atributo como example.com . Mas se você quiser compartilhar cookies entre sub1.app.example.com e sub2.app.example.com , você deve definir o atributo como app.example.com . Qualquer nome de domínio especificado explicitamente sempre incluirá todos os subdomínios que possam existir.
Você pode alterar o atributo por um dos seguintes meios, em ordem de recomendação:
Na configuração do PHP ( php.ini ), encontre a linha com a diretiva session.cookie_domain e altere seu valor conforme desejado, ex:
session.cookie_domain = example.com
O mais cedo possível em sua aplicação e antes de criar a instância Auth , chame ini_set para alterar o valor da diretiva session.cookie_domain conforme desejado, por exemplo:
ini_set ( ' session.cookie_domain ' , ' example.com ' ); Para que isso funcione, session.auto_start deve ser definido como 0 na configuração do PHP ( php.ini ).
O atributo path de um cookie controla para quais diretórios (e subdiretórios) o cookie será válido e, portanto, onde a sessão do usuário e o estado de autenticação estarão disponíveis.
Na maioria dos casos, você desejará disponibilizar cookies para todos os caminhos, ou seja, qualquer diretório e arquivo, começando no diretório raiz. Isso é o que faz um valor de / para o atributo, que também é o padrão recomendado. Você só deve alterar este atributo para um valor diferente, por exemplo, /path/to/subfolder , se quiser restringir em quais diretórios seus cookies estarão disponíveis, por exemplo, para hospedar vários aplicativos lado a lado, em diretórios diferentes, sob o mesmo nome de domínio.
Você pode alterar o atributo por um dos seguintes meios, em ordem de recomendação:
Na configuração do PHP ( php.ini ), encontre a linha com a diretiva session.cookie_path e altere seu valor conforme desejado, ex:
session.cookie_path = /
O mais cedo possível em sua aplicação e antes de criar a instância Auth , chame ini_set para alterar o valor da diretiva session.cookie_path conforme desejado, por exemplo:
ini_set ( ' session.cookie_path ' , ' / ' ); Para que isso funcione, session.auto_start deve ser definido como 0 na configuração do PHP ( php.ini ).
Usando o atributo httponly , você pode controlar se os scripts do lado do cliente, ou seja, JavaScript, devem poder acessar seus cookies ou não. Por motivos de segurança, é melhor negar o acesso de script aos seus cookies, o que reduz os danos que ataques XSS bem-sucedidos contra o seu aplicativo poderiam causar, por exemplo.
Assim, você deve sempre definir httponly como 1 , exceto nos raros casos em que você realmente precisa acessar seus cookies a partir de JavaScript e não consegue encontrar uma solução melhor. Nesses casos, defina o atributo como 0 , mas esteja ciente das consequências.
Você pode alterar o atributo por um dos seguintes meios, em ordem de recomendação:
Na configuração do PHP ( php.ini ), encontre a linha com a diretiva session.cookie_httponly e altere seu valor conforme desejado, ex:
session.cookie_httponly = 1
O mais cedo possível em sua aplicação e antes de criar a instância Auth , chame ini_set para alterar o valor da diretiva session.cookie_httponly conforme desejado, por exemplo:
ini_set ( ' session.cookie_httponly ' , 1 ); Para que isso funcione, session.auto_start deve ser definido como 0 na configuração do PHP ( php.ini ).
Usando o atributo secure , você pode controlar se os cookies devem ser enviados por qualquer conexão, incluindo HTTP simples, ou se uma conexão segura, ou seja, HTTPS (com SSL/TLS), deve ser necessária. O primeiro modo (menos seguro) pode ser escolhido definindo o atributo como 0 , e o último modo (mais seguro) pode ser escolhido definindo o atributo como 1 .
Obviamente, isso depende apenas de você conseguir atender todas as páginas exclusivamente via HTTPS. Se possível, você deve definir o atributo como 1 e possivelmente combiná-lo com redirecionamentos HTTP para o protocolo seguro e HTTP Strict Transport Security (HSTS). Caso contrário, talvez seja necessário manter o atributo definido como 0 .
Você pode alterar o atributo por um dos seguintes meios, em ordem de recomendação:
Na configuração do PHP ( php.ini ), encontre a linha com a diretiva session.cookie_secure e altere seu valor conforme desejado, ex:
session.cookie_secure = 1
O mais cedo possível em sua aplicação e antes de criar a instância Auth , chame ini_set para alterar o valor da diretiva session.cookie_secure conforme desejado, por exemplo:
ini_set ( ' session.cookie_secure ' , 1 ); Para que isso funcione, session.auto_start deve ser definido como 0 na configuração do PHP ( php.ini ).
$ length = 24 ;
$ randomStr = Delight Auth Auth:: createRandomString ( $ length ); $ uuid = Delight Auth Auth:: createUuid ();Para obter informações detalhadas sobre como ler e gravar dados de sessão de maneira conveniente, consulte a documentação da biblioteca de sessões, que está incluída por padrão.
Qualquer senha ou token de autenticação é automaticamente criptografado usando a função “bcrypt”, que é baseada na cifra “Blowfish” e (ainda) considerada uma das funções de hash de senha mais fortes da atualidade. “bcrypt” é usado com 1.024 iterações, ou seja, um fator de “custo” de 10. Um “sal” aleatório também é aplicado automaticamente.
Você pode verificar essa configuração observando os hashes na tabela do banco de dados users . Se o acima for verdade com sua configuração, todos os hashes de senha em sua tabela users devem começar com o prefixo $2$10$ , $2a$10$ ou $2y$10$ .
Quando novos algoritmos (como Argon2) forem introduzidos no futuro, esta biblioteca cuidará automaticamente de “atualizar” seus hashes de senha existentes sempre que um usuário fizer login ou alterar sua senha.
Aplicar um comprimento mínimo para senhas geralmente é uma boa ideia. Além disso, você pode querer verificar se uma senha potencial está em alguma lista negra, que você pode gerenciar em um banco de dados ou em um arquivo, para evitar que palavras de dicionário ou senhas comumente usadas sejam usadas em seu aplicativo.
Para permitir máxima flexibilidade e facilidade de uso, esta biblioteca foi projetada para não conter nenhuma verificação adicional de requisitos de senha, mas em vez disso permite que você agrupe suas próprias verificações em torno das chamadas relevantes aos métodos da biblioteca. Exemplo:
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 );
} Você pode tentar carregar esta biblioteca primeiro e criar a instância Auth primeiro, antes de carregar as outras bibliotecas. Além disso, provavelmente não há muito que possamos fazer aqui.
Se quiser permitir que outras pessoas incluam seu site em um elemento <frame> , <iframe> , <object> , <embed> ou <applet> , você deve desabilitar a prevenção padrão de clickjacking:
header_remove ( ' X-Frame-Options ' );Esta biblioteca lança dois tipos de exceções para indicar problemas:
AuthException e suas subclasses são lançadas sempre que um método não é concluído com êxito. Você deve sempre capturar essas exceções, pois elas carregam as respostas de erro normais às quais você deve reagir.AuthError e suas subclasses são lançadas sempre que há um problema interno ou a biblioteca não foi instalada corretamente. Você não deve capturar essas exceções. Todas as contribuições são bem-vindas! Se você deseja contribuir, crie um problema primeiro para que seu recurso, problema ou pergunta possa ser discutido.
Este projeto está licenciado nos termos da licença do MIT.
