Laravel5 빠른 인증 로직 흐름 분석-PHP 튜토리얼-php.cn

이 글은 Laravel5의 빠른 인증 로직 프로세스에 대한 분석을 주로 소개합니다. 이제는 모든 사람과 공유합니다. 도움이 필요한 친구들은 이를 참조할 수 있습니다.

Laravel5 자체에는 일련의 사용자 인증 기능만 포함되어 있습니다. 프로젝트 아래에서 command line을 사용하세요php artisan make:auth 和 php artisan migrate就可以使用自带的快速认证功能。

다음은 Laravel 5.5 버전을 기준으로 로그인 기능을 논리적으로 분석한 것입니다.

php artisan Route:list 명령을 통해 로그인 경로(빨간색 상자)를 가져옵니다.

/app/Http/Controller/Auth/LoginController.php를 열고 확인합니다. 실제로 파일 코드는 매우 간단합니다. 로그인 로직과 메소드는 Illuminate/Foundation/Auth/AuthenticatesUsers의 특성에 통합되어 있습니다:

IlluminateFoundationAuthAuthenticatesUsers 코드의 로그인 메소드 보기 $request 매개변수는 다음을 포함한 로그인 요청 정보를 포함하는 요청 객체입니다. 로그인 이름, 비밀번호 등:

line31 : verifyLogin 메소드는 사용자 이름과 비밀번호가 간단한 규칙을 준수하는지 확인하기 위해 컨트롤러의 자체 유효성 검사 메소드를 호출하는 역할을 합니다. 깊이.

빨간색 상자에 표시된 사용자 이름 방법에 주목할 가치가 있습니다. 개발자는 LoginController에서 이 방법을 사용자 정의하여 특성 방법을 재정의하고 특성 기본값을 'email'로 사용자 정의할 수 있습니다.

Laravel5 프레임워크의 무결성을 유지하기 위해 특성의 사용자 이름() 메서드를 직접 변경하지 마세요. 이유는 자세히 설명되지 않습니다.

line36: hasTooManyLoginAttempts 메소드는 계정에 대한 로그인 시도 횟수가 설정된 최대값에 도달했는지 확인하는 데 사용됩니다.

이 방법은 IlluminateFoundationAuthThrottlesLogins의 특성을 나타냅니다. 특성 이름을 보면 폭력적인 로그인을 방지하는 역할을 담당하고 있음을 짐작할 수 있습니다. 위 그림의

limiter()는 앱 서비스 컨테이너에서 생성된 RateLimiter 개체(이름에서 알 수 있듯이 주파수 제한기)를 반환합니다. 이 객체는 IlluminateCacheRateLimiter 파일에서 시작됩니다.

이 객체의 위치에서 볼 수 있듯이 Laravel 캐싱 메커니즘을 사용하여 로그인 수를 처리합니다.

따라서 위 그림의 hasTooManyLoginAttempts 메소드는 로그인 횟수를 확인하기 위해 RateLimiter 객체의 tooManyAttempts 메소드를 호출합니다.

tooManyAttempt 메소드에는 세 가지 매개변수가 있습니다.

$key: 해당 항목을 저장하기 위해 캐시에 사용됩니다. 현재 계정 키의 로그인 번호 값입니다. 키 구성은 다음과 같습니다:

키 값은 대략 다음과 같습니다: "email|101:10:45:12". 무차별 대입 크래킹 방지에는 IP를 사용하고 있음을 알 수 있습니다. 물론 IP를 변경하면 다시 로그인을 시도할 수 있지만 항상 제한이 있지만 알몸인 것보다는 훨씬 낫습니다.

$maxAttempts: 최대 로그인 시도 횟수 설정 값입니다.

이 값은 사용자 정의 가능하며 LoginController의 사용자 정의 maxAttempts 속성에 작성할 수 있습니다. 기본값은 5회입니다.

$decayMinutes: 최대 횟수에 도달한 후 로그인을 재개하는 데 걸리는 대기 시간(분)입니다. 시도.

이 값은 LoginController에서 사용자 정의할 수 있습니다. 기본값은 1분입니다.

이 메소드는 현재 로그인 수가 설정된 값에 도달하는지 여부를 결정합니다. 설정된 값에 도달하면, 값이 설정되고 여전히 마지막 로그인 금지 시간 범위 내에 있으면 true가 반환되어 현재 사용자(IP)가 여전히 로그인 금지 상태에 있음을 나타냅니다.

아래 그림의 빨간색 상자는 캐시에 $key.':timer' 값이 있는지 확인하는 데 사용됩니다. 이 값은 위의 $decayMinutes 시간을 만료 시간으로 사용하므로 이 값의 존재를 사용합니다. 로그인 상태 키를 복원합니다.

캐시 값이 없으면 현재 사용자가 로그인할 수 있습니다. 이때, ResetAttempts 메소드는 $key 캐시 로그인 횟수 값을 지우고 0부터 기록을 시작합니다.

코드 실행 권한은 다시 IlluminateFoundationAuthAuthenticatesUsers의 36번째 줄로 돌아갑니다:

hasTooManyLoginAttempts가 true를 반환하면 Lockout 이벤트가 시작되고 LockoutResponse 응답이 반환됩니다. 사용자는 로그인 로그 기록 등 이벤트 관련 로직을 처리하기 위해 잠금 이벤트 모니터를 생성할 수 있습니다.

LockoutResponse는 본질적으로 확인 예외를 발생시킵니다. 이는 Laravel에 의해 자동으로 423 상태 코드가 있는 응답으로 해석되고 auth.throttle 구성 정보와 함께 제공됩니다. 이 구성의 원래 언어는 /resources/lang/en/auth.php에 있습니다. 사용자는 자신의 언어 정보를 사용자 정의할 수 있습니다.

그런 다음 IlluminateFoundationAuthAuthenticatesUsers의 42번째 줄로 돌아가서 로그인 확인을 시작합니다.

attemptLogin 메소드는 config/auth.php에 구성된 가드 이름을 통해 해당 가드 개체를 생성한 다음 개체의 로그인 확인 시도를 호출합니다. .

Laravel5 가드는 현재 SessionGuard와 tokenGuard 두 가지 유형을 지원하며 둘 다 IlluminateAuth 폴더에 저장되어 있으므로 둘 다 IlluminateContractsAuthGuard 인터페이스에 구현되어 있으므로 가드를 사용자 정의해야 하는 경우 이 인터페이스를 구현하십시오.
웹 가드를 구현하려는 경우 IlluminateContractsAuthStatefulGuard 인터페이스를 추가로 구현할 수 있습니다.

어떤 경우에 어떤 가드를 사용할지는 config/auth.php에 설정되어 있습니다:

이번에는 웹 로그인 프로세스를 분석하고 있으므로 IlluminateAuthsessionGuard의 시도 방법을 확인하고 싶습니다:

라인 351: 이 라인의 기능은 구성된 공급자 공급자를 통해 계정 정보를 검색하는 것입니다. 또한 DatabaseUserProvider와 EloquentUserProvider라는 두 가지 유형의 공급자가 있습니다. 파일은 /Illuminate/Auth에 있습니다.

사용할 특정 공급자는 config/auth.php의 공급자 매개변수를 통해 구성됩니다. 구성 후 'guards' 매개변수에서 사용할 공급자도 지정해야 합니다. 공급자는 기본적으로 데이터베이스 계정 테이블을 쿼리하는 방법을 제공합니다. 데이터베이스는 데이터베이스 Db 파사드를 직접 사용하여 쿼리하는 반면 Eloquent는 모델을 사용하여 쿼리합니다.

Laravel은 기본적으로 EloquentUserProvider를 사용합니다.retrieveByCredentials 메소드를 살펴보면 사용자 정보가 계정 이름으로 직접 검색된다는 것을 알 수 있습니다.

IlluminateAuthsessionGuard의 시도 메소드로 돌아가서 356행의 hasValidCredentials 메소드는 비밀번호를 입력하면 이전 단계의 사용자 정보를 정상적으로 검색할 수 있습니다.

hasValidCredentials 메소드 본문에서 볼 수 있듯이 비밀번호 확인을 위해 공급자의 verifyCredentials 메소드를 호출합니다. EloquentUserProvider::validateCredentials 메소드를 확인하세요:

이 확인 메소드는 HasherContract 계약에 의해 구현된 해시 클래스의 check 메소드를 사용합니다. 구체적인 구현 클래스는 다음과 같습니다: IlluminateHashingBcryptHasher. 이 클래스의 확인 방법을 살펴보겠습니다.

분명히, 이 클래스는 입력된 일반 텍스트 비밀번호와 해시된 비밀번호 값을 비교하기 위해 Password_verify 함수를 사용합니다. 이를 위해서는 데이터베이스 비밀번호가 Password_hash를 사용하여 해시되어야 합니다.

비밀번호 확인에 성공하면 true를 반환합니다. sessionGuard로 돌아와 line357의 로그인 메소드를 실행하여 세션 및 쿠키 로그인 상태를 기록합니다.

저장된 세션의 키와 값은 다음과 같습니다.

'key'=>'login_session_'.sha1(static::class) //static::class는 sessionGuard 클래스 자체를 참조합니다

'value ' =>현재 사용자의 기본 키 값

member_me 옵션을 사용하면 다음 쿠키가 저장되며, 키와 값은 다음과 같습니다.

'key'=>''remember_session_'.sha1( static::class) //static ::class는 sessionGuard 클래스 자체를 참조합니다

'value'=>사용자 기본 키 값.'|'.마지막으로 기억된_token 값이 저장되었습니다.'|'.사용자 비밀번호 해시 값

At 이 시점에서 사용자는 성공적으로 로그인했으며 실행 지점은 마침내 IlluminateFoundationAuthAuthenticatesUsers의 42번째 라인으로 반환되고, tryLogin이 실행되어 true를 반환한 다음 로그인 후 메인 페이지 또는 마지막 로그인 페이지로 이동하기 위해 sendLoginResponse 메소드가 호출됩니다.

인증된 메서드는 빈 메서드라는 점에 유의하세요. LoginController에서 이 메서드를 재정의하여 로그인 후 다른 로직을 점프하고 처리하는 방법을 맞춤설정할 수 있습니다.

로그인에 실패하면 IlluminateFoundationAuthAuthenticatesUsers의 incrementLoginAttempts($request) 메서드를 실행하여 로그인 실패 횟수를 늘립니다. 횟수를 늘리는 방법도 RateLimiter 클래스의 hit() 메소드를 간접적으로 호출하는 것이다.
마지막으로 sendFailedLoginResponse를 호출하여 로그인 예외를 반환합니다.

마지막으로 타이밍 다이어그램이 첨부되었습니다. 일부 UML 개념이 잘 파악되지 않았습니다.