Пользователь не может войти, когда администратор вошел в систему
У меня проблема в моем проекте. Когда администратор вошел в систему, ни один пользователь не может войти в тот же браузер, почему это происходит? Но когда я уничтожаю куки и затем пытаюсь войти в систему как пользователь, он правильно входит в систему.
Как я могу решить это?
Решение
Любой крупный браузер будет хранить только один сеансовый файл cookie для сайта, но разработчик сайта может выбрать, что находится в этом файле cookie. Похоже, что ваш сайт хранит информацию о пользователе в файле cookie сеанса, который затем перезаписывается, когда другая вкладка хранит различную информацию в том же файле cookie.
Вы не предоставляете много подробностей о том, как работает ваш конкретный сайт, но вот несколько общих способов решения этой проблемы.
1) Используйте разные браузеры для разных пользователей. Разные браузеры не делят куки между ними. Если ваша цель — просто протестировать свой сайт с несколькими пользователями, это путь. Вы также можете использовать режим Инкогнито / Личный для входа в систему отдельного пользователя, так как в этом режиме также не используются файлы cookie.
2) Не используйте сеансовые куки для хранения пользовательской информации. На большинстве веб-сайтов это не является началом работы, но если это внутренний сайт или строго контролируемая среда, вы можете передать идентификацию пользователя через URL, данные POST или какой-либо другой скрытый идентификатор в запросе.
3) Сохранение данных в файле cookie сеанса для всех зарегистрированных пользователей. В зависимости от веб-фреймворка, возможно, можно создать карту user -> cookieData и найти правильную карту, в зависимости от того, какой пользователь делает запрос. Это продвинутая техника, и я на самом деле не знаю, выставляет ли Laravel этот уровень контроля.
Другие решения
Harshad очень хорошо охватывает все аспекты, но я могу рассказать о небольшом приеме, который я использовал, когда хотел протестировать, используя разные права пользователя (один и тот же браузер). В моем случае это была аутентификация Windows, но это не имеет значения:
1) определить флаг на уровне пользователя (например, SuperUser). Это может быть 0 (false) или 1 (true).
2) разрешить «подражание» — если у администратора установлен флаг SuperUser, он / она может изменить свои роли / права и увидеть сайт, как будто он / она является обычным пользователем с такими конкретными правами, но раздел управления пользователями по-прежнему доступен, чтобы разрешить изменение прав назад.
3) В разделе управления пользователями требуются небольшие изменения, чтобы SuperUser реализация безопасности (то есть раздел показывает, если у пользователя нет роли администратора, но он помечен как SuperUser)
Таким образом, вы тестируете как один пользователь, не требуется многократные сеансовые куки или другие хитрости. Вы можете открыть одну вкладку с вашим профилем пользователя и другие, чтобы провести реальное тестирование.
Замечания: Что касается предложения с несколькими браузерами, то это быстрое решение для разработчиков, но в корпоративной среде это может быть реальной проблемой, поскольку пользователи (например, ключевые пользователи, которые должны тестировать безопасность) не имеют доступа к более чем одному браузеру.