Как сохранить атрибуты сеанса в многопользовательской архитектуре?

Question

В случае приложений SaaS, где один и тот же сервер воспроизводит несколько приложений. Как поддерживаются атрибуты сеанса? Чтобы уточнить вопрос: AppA и AppB размещены на одном компьютере, теперь я создаю UserA для AppA и UserB для AppB. AppA и AppB принадлежат разным организациям, поэтому они не связаны между собой. Некоторые сведения о пользователе хранятся на уровне сеанса http (до истечения времени ожидания сеанса). Так что теперь, если я вхожу в AppA и AppB из одного и того же браузера с использованием разных вкладок, я могу в конечном итоге увидеть некоторые детали UserA / AppA на экране UserB / AppB или наоборот. Как решить эту проблему? Я могу подумать, что одним из решений является создание поддоменов, таких как appa.example.org и appb.example.org. Есть ли другой / лучший способ?

Answer 1

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

<Service ...>
    <Engine ...>
        <Host ... autoDeploy="false">
            <Context docBase="myapp.war" path="/tenant1"/>
            <Context docBase="myapp.war" path="/tenant2"/>
        </Host>
    </Engine>
</Service>

По сути, это то же самое, что создание копий myapp.war под названием tenant1.war, tenant2.war и т. Д. Каждый арендатор технически управляет своимсобственное веб-приложение, даже если все они используют один и тот же код.Если у вас есть пользователи с учетными данными на двух или более арендаторах, они могут войти в систему обоих одновременно, и каждое веб-приложение получит свой собственный сеанс, поскольку каждый из файлов cookie JSESSIONID, содержащих идентификатор сеанса, связан с определенным контекстным путем.

У этого подхода есть недостатки.Во-первых, все классы в файле войны перезагружаются для каждого арендатора, поэтому мне придется следить за пространством PermGen.Во-вторых, мне придется редактировать server.xml каждый раз, когда появляется новый клиент.Вы нашли лучшее решение?

Answer 2

Обычно вы не увидите подробностей из одного приложения в другом.

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

Если вы представите этот идентификатор сеанса в другом веб-приложении, он не найдет атрибуты, потому что они находятся в другом веб-приложении.

Теперь это "нормально". На практике это может быть настроено во всех направлениях, например, сохранение всех атрибутов в cookie (очень полезно в сценариях экстремального переключения при отказе), сохранение сеанса в общем слое memcached или в таблице общих баз данных (тогда вы получите тот же объект обратно в другом приложение, конечно), и так далее, и так далее.