Fixed : Even though you activate the user who gets inactivated by fai… #8528
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull request is to fix issue #8449.
In UserLoginAttempts table, utcDate field type is timestamp.
{ $after = Carbon::now('UTC')->subSeconds($duration); } returns a Datetime value which has to be converted into a timestamp value before being passed on to the following where clause:
{ $qb->where('a.utcDate > :after')->setParameter('after', $after->getTimestamp()); }
Otherwise, it would come down to comparing a Datetime value with a timestamp value which returns uncertain results.
Once a user failed to login several times and has been deactivated, then reactivated, next times that user wants to log back in, all past failed login attempts are fetched from the database instead of those that occured within the duration specified in concrete.user.deactivation.duration and that's why after a single login attempt failure again, the user will be deactivated.
This code line { return max(0, $allowed - $attempts); } in function remainingAttempts() would then almost always return 0 since $allowed < $attempts which is a malfunction.
However even after adding this modification to the code, in case a reactivated user wants to log back in within concrete.user.deactivation.duration, they will still be deactivated after a single login attempt failure since previous login attempt failures are not cleared from the database, which is a normal behaviour of the system in my opinion. But whether past login attempt failures should be deleted from the database or not after a user has been deactivated and then reactivated is up to the core team.