Ответ 1

Laravel Session Background

Сессия

Пропустите этот раздел для быстрого простого решения.

В Laravel файлы cookie сеанса создаются с помощью класса Illuminate\Session\SessionManager, а именно с помощью метода buildSession:

SessionManager:: buildSession

protected function buildSession($handler)
{
    if ($this->app['config']['session.encrypt']) {
        return new EncryptedStore(
            $this->app['config']['session.cookie'], $handler, $this->app['encrypter']
        );
    } else {
        return new Store($this->app['config']['session.cookie'], $handler);
    }
}

В этом методе мы можем ясно видеть, что имя сеанса происходит от нашего config\session.php, в частности, в этой строке:

session.php

'cookie' => 'laravel_session', # ~~ ln 121 at time of writing

Хорошо, но это не очень помогает, изменяя это, меняет его везде, как отмечено комментарием, которое продолжается в конфиге.

Указанное здесь имя будет использоваться каждый раз, когда новый cookie сеанса создается каркасом для каждого драйвера.

И даже если бы мы могли передать ему какое-то динамическое значение, например:

'cookie' => 'laravel_session' . user()->id,

Это создает парадоксальное, окончательное окончание окончания объекта, потому что вы запрашиваете id из user, к которому обращается через session, который просматривается под именем cookie laravel_session.. (mindblown )

Оставьте SessionManager и конфигурацию session.php. Мы можем видеть сверху, что независимо от того, как мы к этому подходим, вся наша информация о сеансе будет подпадать под этот единственный ключ laravel_session.

Guard

Возможно, у Guard будет дополнительная информация.

Guard - это ваш ключ к авторизации в вашем приложении, и одна из многих вещей, которые делают Laravel потрясающим для быстрого создания приложений.

Метод просмотра - Guard::user().

Одна из первых вещей Guard::user() делает после некоторой начальной проверки кеша и выхода из системы, является проверкой сеанса.

Guard:: пользователь()

$id = $this->session->get($this->getName()); 

Итак, Laravel извлекает значения сеанса, соответствующие результату getName() - awesome - все, что нам нужно сделать, это mod getName(), чтобы вернуть значение, чтобы взять взятый при этом метод:

Guard:: GetName()

public function getName()
{
    return 'login_'.md5(get_class($this));
}

Это довольно прямолинейно. $this относится к классу Guard, поэтому md5 будет всегда всегда быть одинаковым (если кто-то знает, почему "за" md5'а имя класса будет одинаковым каждый раз, оставьте комментарий).

Есть несколько мест, где это должно быть обновлено, например getRecallerName.

Итак, вы можете расширить класс Guard и сплайсинг в методах getName и getRecallerName.

Возможно, вам захочется обернуть некоторый сервис-провайдер, напишите некоторые модульные тесты, возможно, даже перезапишите оригинальный менеджер auth.

"Геэз, похоже, много работы"

"Конечно, это Билли, он уверен, что"

https://www.youtube.com/watch?v=dTxQ9yhGnAg

См. следующую часть

Быстрый ответ "Мне просто нужен ответ"

Ollie Read уже создал решение, найденное здесь:

https://github.com/ollieread/multiauth

Я рекомендую вам взглянуть, особенно пользовательский класс Guard, который расширяет core Guard с помощью пользовательских методов getName.

Ответ 2

Любой крупный браузер будет хранить только один куки файл сеанса для сайта, но разработчик сайта может выбрать, что в этом файле cookie. Кажется, что ваш сайт хранит информацию пользователя в cookie сеанса, который затем перезаписывается, когда другая вкладка хранит различную информацию в том же файле cookie.

Вы не можете подробно рассказать о том, как работает ваш конкретный сайт, но вот несколько общих способов решения этой проблемы.

1) Использовать разные браузеры для разных пользователей. Различные браузеры не используют файлы cookie между ними. Если ваша цель - просто протестировать ваш сайт с несколькими пользователями, это так. Вы также можете использовать режим Incognito/Private для входа отдельного пользователя, так как этот режим не поддерживает файлы cookie.

2) Не используйте файлы cookie cookie для хранения информации о пользователе. Это не стартер на большинстве веб-сайтов, но если это внутренний сайт или строго контролируемая среда, вы можете пройти идентификацию пользователя через URL-адрес, данные POST или какой-либо другой скрытый идентификатор в запросе.

3) Сохранять данные в файле cookie сеанса для всех зарегистрированных в настоящее время пользователей. В зависимости от веб-структуры может быть возможно создать карту user → cookieData и посмотреть на основе того, какой пользователь выполняет запрос. Это расширенный метод, и я действительно не знаю, раскрывает ли Laravel этот уровень контроля.

Ответ 3

tl; dr: Yagni

Рассмотрим человека (http-клиент в вашем случае) с двумя идентификаторами: Dr Jekyll и Mr Hyde.
Он посещает своего нового друга Sir RM1970 (http-сервер в вашем случае): "Как вы это делаете, RM1970!".
Вот проблема. Бедный RM1970 должен приветствовать монстра, и есть несколько вариантов:

• углубляйтесь в эту кроличью нору: "Как вы выполняете как Dr Jekyll, так и Mr Hyde!", что невероятно усложняет дальнейшую беседу (например, ваш ACl должен будет работать со списком идентификаторов и сделать решение о приоритетах, если они конфликтуют в реальном времени)
• принять решение самостоятельно: "Как вы это делаете Dr Jekyll!" и молитесь, чтобы вы сделали правильный выбор (случайно выберите идентификатор пользователя и принесите своим пользователям удовольствие от непредсказуемых ответов).
• быть лукавым и отнести эту ответственность к нему: "Простите меня? Кто вы? Назовите себя!" (для каждого запроса требуется одиночный)

Позднее, как это работает. Браузер обеспечивает последнюю подтвержденную идентификацию.
Вас попросили изменить это, но вы действительно этого хотите? Держите линию и не принимайте эту ответственность.
Если вы не собираетесь использовать первые два тупиковых варианта, вам нужно будет спросить пользователя, от какого имени он отправляет запрос. Самый лучший вариант здесь - сделать свой внешний вид stateful, поддерживать список открытых сеансов и предоставить пользовательский интерфейс для пользователя. Это почти третий вариант Ryan Bemrose, но сохраните эти данные на стороне клиента и отправьте только выбранную. Никаких изменений в брандмауэре laravel не требуется.

Проблема здесь в переключении вкладок не будет автоматически переключать пользователя, и будет довольно запутанной, обеспечивая очень небольшую разницу с логином/логином пути, который уже реализован.

Некоторые браузеры поддерживают несколько профилей (пример), что может быть приемлемой альтернативой. В основном это то же самое, что и первый вариант Ryan Bemrose, но не требует установки нескольких браузеров и может использовать постоянные файлы cookie, также известные как "Remember-me".

Ответ 4

Самый простой - это только идентификатор сеанса, основанный на URL, который может быть проблемой безопасности в зависимости от того, как ваше приложение разработано, особенно при совместном использовании URL-адресов с неистекшими сеансами.

Поскольку L5 больше не поддерживает собственные сеансы php, вам придется использовать настраиваемый поставщик, как показано ниже:

Это будет использовать sessionID в URL-адресе для laravel V5:

https://github.com/iMi-digital/laravel-transsid

В основном сеанс основан на URL-адресе, поэтому вы можете просто войти на другую вкладку и получить новый идентификатор сеанса, и этот человек может легко сделать "открытую страницу на новой вкладке", чтобы иметь две страницы одного и того же пользователя, если это необходимо хорошо.

Библиотека выше блокирует сеанс для IP и User Agent, поэтому совместное использование ссылок не приведет к случайному утечке сеанса.

Ответ 5

Я точно не знаю, для чего вам это нужно, но как разработчик мне иногда приходится входить в приложение с несколькими пользователями. Для этого я обычно использую режим инкогнито, или если у него более двух пользователей, мне посчастливилось использовать это расширение в хром.

Я знаю, что это не ответ на ваш вопрос, но это может быть то, что вы ищете.

Ответ 6

Различные видения, сосуществующие между одновременными зарегистрированными пользователями, не могут быть реализованы только cookie сеанса, потому что cookie хранится браузером. Таким образом, журнал в элементе пользователя должен храниться на сервере. Как известно, после вызова session_start создается SessionID, а затем создается временный файл на сервере каталог.

У разного пользователя есть другой SessionID и после session_destory, то все SessionID, хранящиеся в Сервере и Cookies, восстанавливаются. Вы можете переписать это поведение, выполнив SessionHandlerInterface. Из-за этого многие веб-среды поддерживают это, Laravel не исключение. Вот документ: custom-session-drivers

Ответ 7

Я не знаю, как сложно усваивать его в laravel, но это может быть одно решение:

Вы используете другое имя сеанса, должны быть строкой и каждый раз вводить ее в URL-адрес, чтобы приложение узнало, какой пользователь сделал запрос. Таким образом, вы можете вызывать переменные сеанса обычным именем.

<?php
if(isset($_GET['id']) && !empty($_GET['id']))
    session_name($_GET['id']);
session_start();

if(isset($_GET['user'])) {
    $_SESSION['user'] = $_GET['user'];
}

if(!empty($_SESSION['user']))
    echo "Hello ".$_SESSION['user'];

Ответ 8

Multi userlogin с тем же браузером, что и google add account. для этого вам нужно выполнить несколько шагов и перезаписать auth-библиотеку, предоставленную Laravel,

Шаги

Сделайте резервную копию вашего файла Auth.

Измените все функции хранилища сеансов, чтобы сначала сохранить его в массиве, а затем сохранить этот массив в сеансе

Теперь вам нужно создать новую переменную сеанса, которая сохранит текущий идентификатор экземпляра пользователя, такой как user 0 1 2...

Теперь вам нужно изменить всю функцию, вы получите значения из сеанса, которые вам нужны, чтобы проверить, не является ли объект сеанса пустым, а затем пользователь выходит из системы, иначе вам нужно получить данные из базы пользователей в экземпляре пользователя.

Вам нужно изменить свой экземпляр, когда пользователь хочет переключиться с одной учетной записи на другую.