Я изо всех сил пытаюсь решить, как лучше всего добавить аутентификацию и авторизацию в свою службу SignalR.SignalR токен авторизации подачи
На данный момент он размещен в Овине вместе с веб-сервисом WebApi2. Я использую токены-носители OAuth2 для аутентификации с ними, и он работает отлично. Однако, интересно, подходят ли они для SignalR?
Мой клиент основан на JavaScript, а SignalR использует WebSockets, если он доступен. Это означает, что я не могу использовать заголовок авторизации. Я понял, что я могу предоставить токен, используя свойство qs, прежде чем подключаться. Но, конечно же, токен доступа OAuth2 истекает (и относительно коротко в моей реализации). Я предполагаю, что обновление свойства qs не будет иметь никакого значения после подключения (особенно с веб-сокетами).
Я полагаю, что мой вопрос - это лучший способ предоставить токен безопасности, билет или любую информацию авторизации в SignalR? Предпочтительно способ, который может быть согласован как на моем WebApi, так и на SignalR, но я хочу знать, как это сделать .
Благодаря
Вы ознакомились с инструкцией по signalR по безопасности? на http://www.asp.net/signalr/overview/signalr-20/security/hub-authorization –
Я просмотрел его, но, похоже, он больше сосредоточен на том, как SignalR смягчает атаки. Я ищу информацию о том, как я * должен * передавать информацию безопасности в SignalR разумным и совместимым способом. т. е. показывать, что я использую файлы cookie? Имеет ли смысл использовать токены доступа? – Barguast
(продолжение) Из того, что я могу сказать, если я использую «qs» для указания токена доступа при подключении, то даже после того, как токен доступа истёк, соединение останется в живых и все еще знает пользователя. Для меня это не проблема, но так ли это? В какой момент мне нужно обновить qs, чтобы предоставить новый токен доступа (на Reconnect?). – Barguast