Дело в особенности языка.
Из-за неточности вычислений с плавающей запятой, очень редко может возникать ситуация неправильного округления. ссылка
Метод floor работает гораздо проще и просто возвращает ближайшее целое число, которое меньше или равно указанному.
Таким образом, вместо ненадежного round() мы умножаем рандомное число на 2, результатом чего всегда будет число в промежутке [0,2) без каких-либо округлений. После чего надежно используем floor() и получаем 0 или 1.
К пункту №15 можно добавить следующее:
Хром сохраняет последние 5 элементов, которые Вы выделяли в панели Element.
Чтобы обратиться к текущему (последнему выбранному) элементу, как и написано в статье, достаточно написать $0, но можно обратиться и к предыдущим: $1, $2, $3 и $4.
Вот несколько заметок, которые помогут улучшить секьюрность при использовании JWT:
1. При создании токена, в его тело необходимо внести IP адрес пользователя. Затем при каждом запросе сверять это поле с тем адресом откуда поступил запрос. Таким образом, даже имея токен, злоумышленник не сможет воспользоваться им. Этот способ накладывает некоторые дополнительные неудобства для пользователя, например придётся авторизовываться заново каждый раз когда меняется его IP. Однако, в большинстве случаев это происходит не очень часто и не должно вызывать особого дискомфорта.
2. Можно, конечно, при каждом запросе дёргать вашу БД и сверять данные из токена с данными в записи пользователя. Иными словами, при каждом запросе обращаться к БД, доставать юзера и убеждаться в том, что данный запрос может быть выполнен, при этом что и как сверять зависит только от вашей задумки. Можно проверять, не заблокирован ли пользователь, не менял ли он пароль с момента выдачи токена, подходящая ли у него роль и т.д. Этот способ довольно грубый, но максимально эффективный. Тем не менее, есть более практичный и интересный способ проверки, не насилующий вашу основную БД — смотрите пункт 3.
3. Хранение списка актуальных токенов (т.н. «белый список») в отдельной высокопроизводительной БД, например Redis или Memcahed. При каждом запросе, после обычной проверки токена на валидность, мы также проверяем его наличие в этой БД. Если по какой-то причине его там не оказалось — значит запрос не может быть выполнен и нужно получить новый токен. Таким образом, после каких-то критических действий с аккаунтом (смена пароля, смена роли, бан и т.д.) мы просто удаляем из белого списка все токены, относящиеся к этому аккаунту.
Из-за неточности вычислений с плавающей запятой, очень редко может возникать ситуация неправильного округления. ссылка
Метод floor работает гораздо проще и просто возвращает ближайшее целое число, которое меньше или равно указанному.
Таким образом, вместо ненадежного round() мы умножаем рандомное число на 2, результатом чего всегда будет число в промежутке [0,2) без каких-либо округлений. После чего надежно используем floor() и получаем 0 или 1.
Хром сохраняет последние 5 элементов, которые Вы выделяли в панели Element.
Чтобы обратиться к текущему (последнему выбранному) элементу, как и написано в статье, достаточно написать $0, но можно обратиться и к предыдущим: $1, $2, $3 и $4.
1. При создании токена, в его тело необходимо внести IP адрес пользователя. Затем при каждом запросе сверять это поле с тем адресом откуда поступил запрос. Таким образом, даже имея токен, злоумышленник не сможет воспользоваться им. Этот способ накладывает некоторые дополнительные неудобства для пользователя, например придётся авторизовываться заново каждый раз когда меняется его IP. Однако, в большинстве случаев это происходит не очень часто и не должно вызывать особого дискомфорта.
2. Можно, конечно, при каждом запросе дёргать вашу БД и сверять данные из токена с данными в записи пользователя. Иными словами, при каждом запросе обращаться к БД, доставать юзера и убеждаться в том, что данный запрос может быть выполнен, при этом что и как сверять зависит только от вашей задумки. Можно проверять, не заблокирован ли пользователь, не менял ли он пароль с момента выдачи токена, подходящая ли у него роль и т.д. Этот способ довольно грубый, но максимально эффективный. Тем не менее, есть более практичный и интересный способ проверки, не насилующий вашу основную БД — смотрите пункт 3.
3. Хранение списка актуальных токенов (т.н. «белый список») в отдельной высокопроизводительной БД, например Redis или Memcahed. При каждом запросе, после обычной проверки токена на валидность, мы также проверяем его наличие в этой БД. Если по какой-то причине его там не оказалось — значит запрос не может быть выполнен и нужно получить новый токен. Таким образом, после каких-то критических действий с аккаунтом (смена пароля, смена роли, бан и т.д.) мы просто удаляем из белого списка все токены, относящиеся к этому аккаунту.