ASP. Net Основной токен-носитель SignalR при согласовании

Question

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

После проверки рукопожатия SignalR похоже, что заголовок авторизации включен в вызов Negotiate. Так как идентификатор соединения возвращается в ответе согласования, сервер может отслеживать, аутентифицирован ли этот идентификатор соединения.

Почему необходимо также добавить маркер канала-носителя в строку запроса соединения Websocket?

Answer 1

Похоже, это ключ к вашему вопросу.

При использовании WebSockets или Server-Sent Events клиент браузера отправляет токен доступа в строке запроса. Получение токена доступа через строку запроса обычно безопасно, так как используется стандартный заголовок авторизации. Всегда используйте HTTPS для обеспечения безопасного сквозного соединения между клиентом и сервером.

Соображения безопасности в ASP. NET Core SignalR

Это альтернатива:

SignalR может использоваться с ASP. NET Базовая аутентификация для привязки пользователя к каждому соединению. В концентраторе данные аутентификации могут быть доступны из свойства HubConnectionContext.User. Аутентификация позволяет хабу вызывать методы для всех соединений, связанных с пользователем. Для получения дополнительной информации см. Управление пользователями и группами в SignalR. Несколько подключений могут быть связаны с одним пользователем.

Аутентификация пользователей, подключающихся к концентратору SignalR

Дополнительно: Однако, я думаю, вы также можете попробовать некоторые инъекции как для сервера, так и для клиента. На сервере например. используйте помощника websocket и на клиенте, например. используйте Promise vs XMLHttpRequest.