OpenID в ситуации с балансировкой нагрузки - PullRequest
Новая
       27

OpenID в ситуации с балансировкой нагрузки

2 голосов
/ 02 июня 2009

Я смотрю на реализацию поставщика OpenID ('OP') с использованием Java + Tomcat / JBoss.

Теперь одна из ключевых особенностей OpenID заключается в том, что

  1. Пользователь связывается с OP и RP и имеет сеанс с обоими сайтами.
  2. OP и RP взаимодействуют друг с другом, чтобы гарантировать, что пользователь ничего не подделал.

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

Общая проблема, которую я боюсь, состоит в том, что RP подключается к OP и заканчивается на сервере приложений, отличном от пользователя.

Мои вопросы:

  • Как правильно справиться с этим?
  • Какая «лучшая» библиотека OpenID для использовать?

Спасибо.

Ответы [ 2 ]

2 голосов
/ 02 июня 2009

Общая проблема, которую я боюсь, состоит в том, что RP подключается к OP и заканчивается на сервере приложений, отличном от пользователя.

Сохранить состояние разговора в общем хранилище. То есть база данных или распределенный кеш . Кэш-память будет быстрее, и вам все равно не понадобится много времени.

Балансировка нагрузки с помощью липких сеансов (все последующие запросы от одного и того же клиента поступают на один и тот же сервер) уменьшит количество обновлений кэша.

(Кластерные сеансы HTTP, которые я намеревался изначально рекомендовать, не будут работать, поскольку один и тот же разговор распространяется между двумя сеансами: пользовательским и прикладным.)

1 голос
/ 04 июня 2009

Со стороны OP единственным специфичным для OpenID состоянием, которое действительно необходимо разделить между машинами в кластере, являются ассоциации (общие секреты и их дескрипторы). И это довольно кешируется; секрет для данного дескриптора ассоциации никогда не меняется, у них четко определено время жизни, и их не должно быть , а . (Если, возможно, вы не используете некоторые RP большого объема, которые используют режим без сохранения состояния.)

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

...