diff options
| author | EA117 <admin@ea117.com> | 2019-07-28 12:25:54 -0500 |
|---|---|---|
| committer | EA117 <admin@ea117.com> | 2019-07-28 12:25:54 -0500 |
| commit | 636fc7fad7dcb61622f23b36141b87ee13a1090d (patch) | |
| tree | 4d88a9f1e82cd2be041fcabf6cdecb9936758ceb /tests/security/hash_test.php | |
| parent | ae62bc46428948cdfbb735c8b9b566d02c0f78f0 (diff) | |
| download | forums-636fc7fad7dcb61622f23b36141b87ee13a1090d.tar forums-636fc7fad7dcb61622f23b36141b87ee13a1090d.tar.gz forums-636fc7fad7dcb61622f23b36141b87ee13a1090d.tar.bz2 forums-636fc7fad7dcb61622f23b36141b87ee13a1090d.tar.xz forums-636fc7fad7dcb61622f23b36141b87ee13a1090d.zip | |
[ticket/16066] Fix FORM_INVALID always returned for banned user.
After the introduction of add_form_key() and check_form_key() calls to
login_box() in phpBB 3.2.6 and later, if a banned user attempts to login,
they receive a "The submitted form was invalid. Try submitting again."
Instead of the message indicating that they are banned, and why.
This is happening because check_ban() actually calls into login_box()
recursively, but after the $user->session_id has been switched to a new
session ID for the logging-on user. Therefore, now that check_form_key()
has been introduced to login_box(), it is impossible for check_form_key()
to succeed during this recursive call.
Fix is to make login_box()'s use of check_form_key() conditional on whether
IN_CHECK_BAN is defined, so that the recursive call does not attempt to
re-validate the form_key again. Note the form_key has already been
successfully verified by the original call into login_box(), prior to calling
into check_ban() and attempting to recursively call login_box(). So the
protection of why check_form_key() was added is still intact with this change.
PHPBB3-16066
Diffstat (limited to 'tests/security/hash_test.php')
0 files changed, 0 insertions, 0 deletions