Null ServerSession на CometD /meta/handshake

Раздел 6.3.6.4 и нижнюю часть раздела 7.2 документации CometD обсуждает, как установить прослушиватель на канале /meta/handshake для сопоставления идентификаторов пользователей с идентификаторами ServerSessions/ServerSession. для использования в личных сообщениях. Однако при прослушивании канала /meta/handshake полученный ServerSession имеет значение null, поэтому создать карту невозможно. Есть предположения?

ОБНОВИТЬ:

На данный момент я предполагаю, что прослушиватель HandshakeHandler (добавленный в канал /meta/handshake в методе initializeMetaChannels BayeuxServerImpl.java) вызывается после или одновременно с пользовательским прослушивателем, который я создал на том же канале. Поскольку HandshakeHandler фактически создает ServerSession, это приводит к тому, что мой пользовательский прослушиватель получает null ServerSession. Это подтверждается тем фактом, что метод canHandshake из BayeuxServer SecurityPolicy, который вызывается HandshakeHandler после создания ServerSession, вызывается после моего пользовательского прослушивателя. Я предполагаю, что документация CometD, в которой говорится, что сопоставление ServerSession с UserID может быть создано из прослушивателя /meta/handshake, является ошибкой.


person Adam    schedule 27.03.2014    source источник
comment
Какая версия CometD?   -  person sbordet    schedule 27.03.2014


Ответы (1)


Ваш обновленный анализ верен.
Документацию следует обновить, так как первая точка, где сеанс будет доступен, находится в SecurityPolicy.canHandshake().
Я отследил эту проблему с помощью http://bugs.cometd.org/browse/COMETD-522.

person sbordet    schedule 28.03.2014
comment
Было бы предпочтительнее, если бы был способ построить карту идентификатора пользователя / ServerSession, не связывая ее с SecurityPolicy. BayeuxServer.SessionListener предоставляет ServerSession, но не предоставляет ServerMessage, так что это не вариант. Очевидно, вы не хотели бы делать это на канале /meta/connect, потому что опрос заставит повторять проверки, чтобы увидеть, есть ли уже userId на карте. Мысли об альтернативном подходе? - person Adam; 28.03.2014
comment
Я не понимаю, почему вы рассматриваете возможность реализации интерфейса с именем SecurityPolicy связь, в то время как реализация интерфейса с именем ServerChannel.MessageListener или BayeuxServer.SessionListener не является связью? А - person sbordet; 29.03.2014
comment
Тем не менее, предложение иметь ServerMessage доступным в SessionListener является разумным и может быть реализовано в CometD 3 (bugs.cometd.org/browse/COMETD-523). SecurityPolicy — это путь, см., например, также: cometd.org/documentation/2 .x/howtos/аутентификация - person sbordet; 29.03.2014
comment
Я думаю, что SecurityPolicy должен управлять вещами, непосредственно связанными с безопасностью. Таким образом, кажется, что логика построения карты идентификаторов пользователей и ServerSession, необходимых для обеспечения доставки личных сообщений, не относится к реализации SecurityPolicy. Напротив, Listener — это более общая конструкция, предназначенная для различных целей. - person Adam; 30.03.2014