Смена состояния пользовательской веб сесси

[rinsk]

Ну а чем это отличается от JSESSIONID ? Не вникал, но подозреваю ява библы или там php держать хеш sessionid<>user для работы. В домино они туда закатали все что можно и сам токен самодостаточен для идентификации на разных хостах... ну днк у него такое) .

 

[lmike]

токен самодостаточен

но его надо генерить по имени и учитывать всякие доминошные заморочки, в случае с $WSRU - просто имя является достаточным, откуда его брать - решение принимается на фронте

 

[rinsk]

$WSRU

имхо - $WSRU это передается в HTTP хидере от фронта - откуда он его взял - большой оч уж вопрос. В любом случае тот же фронт уже должен иметь CAS и т.п. плюшки.
Я вот не уверен, но по моему домино получив в хидере эти $WS* всего лишь получает REMOTE_USER и никак в процессе работы с АСЛ не участвует, единственно только логирование http сессий.
Было в настройках такое как front-end на IIS. но там необходимо было подкладывать специальные библиотеки от домино.

 

[lmike]

Я вот не уверен, но по моему домино получив в хидере эти $WS* всего лишь получает REMOTE_USER и никак в процессе работы с АСЛ не участвует, единственно только логирование http сессий.

проверял - реально становился юзером - все ридерсы и прочая соблюдались
[DOUBLEPOST=1438618516,1438618376][/DOUBLEPOST]ссылку уже здесь приводил

Ссылка скрыта от гостей

 

[rinsk]

Прочитал внимательно про HTTPEnableConnectorHeaders - да, действительно - оно доверяет заголовку $WSRU и ему вообще больше ничего не нужно)
Посмотрим где можно применить)
В моем случае куча сервисов на разных платформах, написанных всяких php\java\node.js сидят за одним прокси и каждый реализовал свой интерфейс с CAS.

 

[lmike]

домина 9.0.1, nginx и OS разные (CentOS 6.5 и Ubuntu 12.04)
[DOUBLEPOST=1438619086,1438619010][/DOUBLEPOST]

и ему вообще больше ничего не нужно)

ну вот я об этом - путь упрощается
правда аутентификацию надо мутить уже для фронта
[DOUBLEPOST=1438619190][/DOUBLEPOST]для сертификатов - просто таблицу на фронт, с соответствием (на немже и генерация сертификатов) - в Админской части уже описывал
[DOUBLEPOST=1438619369][/DOUBLEPOST]ОС и нжинкс упомянул просто для инфы, но домина ведет себя странно...
одна установлена с 0, др. - апдейтом с 7-8.5-9.0.1 (в теч. жизненного цикла)
во втором варианте - в логи не пишет соотв. значения хэдера, хотя на $WSRU реагирует "штатно"
хэдеры сверял по tcpdump - никаких особенностей

 

[rinsk]

Немного погрузился в тему и как то не нашел универсальной и однозначно рабочей связки nginx+CAS+SPNEGO+SAML... (
все же имхо кесарю - кесарево, как фронт nqinx рулит, а вот authentication service там реализуются кривовато ибо оно довольно тесно связано именно с бакэндом...

 

[lmike]

здесь возвращаемся к токенам

Ссылка скрыта от гостей

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

 

[rinsk]

вот вот - в принципе получаются те же самые токены, которые приклада должна так или иначе анализировать в каждом http запросе...
так что завязка в данном случае на домино токен имхо оправдано...
Причем если по факту пользователя нет в домино директории, то и с лицензионной точки зрения облегчается его использование.
И еще фишка - если такого пользователя не заводить в АК а просто сделать членом группы - то нормально отрабатывает все АСЛ... и как бы пользователя нет в АК как такового ))

 

[erdi]

при проксировании запросов с русским именем пользователя в $WSRU, на сервере получаю крякозябли, при английской раскладке соответственно все нормально. Есть какое-то решение или настройки для решения данной проблемы?

 

[lmike]

имя отправляет клиент в к-л кодировке, а вот какую ждет сервер... - загадка