Почему логика авторизации в дизайне панели управления OpenCart выглядит так (устарела)?

Question

У нас есть множество методов аутентификации и авторизации (OAuth, 2FA и т. Д.) Для обеспечения безопасности нашей учетной записи на платформе электронной коммерции.Недавно я внимательно изучил логику входа в систему администратора OpenCart 3.0.2.0 и попытался выяснить, почему логика авторизации выглядит следующим образом:

1. Хранение маркера пользователя в таблице сеансов в БД (Cool)
2. Хранение зарегистрированного состояния в памяти PHP (Cool)
3. Хранение user_token в браузере администратора (Cool)
4. Укажите срок действия токена до истечения (Cool)
5. Повсюду несите user_token для переменной URL GET (???)

Мы могли бы проверить, является ли user_token от пользователя admin действительным и есть в нашемтаблица сессий в БД (которая проверяется при входе в систему), затем мы можем отслеживать записанное состояние в памяти PHP, также мы можем проверить, не истек ли этот сеанс.

Вопрос в том, почемунам все еще нужно хранить user_token в переменной get url везде?

Answer 1

Переменная user_token была добавлена ​​позже после обсуждения в Интернете этой уязвимости.

Идея токена состояла в том, чтобы запретить хакеру отправлять пользователю ссылку с вредоносным кодом в URL-адресе, которая использовала бы сеанс аутентификации администратора для взлома админ-панели opencart.

С токеном OpenCart проверяет его и выходит из системы администратора в случае, если токен неверен.