invest-openapi
invest-openapi copied to clipboard
Tinkoff
WebSocket frontend
Здравствуйте!
Очень расстраивает отсутствие возможности законнектиться к websocket-api с фронтенда. JS WebSocket в браузерах не поддерживает передачу заголовков, в отличии от NodeJS, а соответственно, нет возможности передать токен. В обход проблемы пришлось поднимать бэкенд ради простого проксирования websocket-трафика. С REST Api проблем нет (CORS позволяет получить доступ). Было бы супер, если появится возможность альтернативной авторизации через браузерный вебсокет:)
Привет!
У нас с предыдущим релизом появился стакан и свечи в REST-протоколе, возможно это сейчас поможет?
@NikitaMelnikov, да, свечами, конечно, на данный момент можно решить вопрос. Но, получив определенные исторические данные, далее хотелось бы получать ивенты об изменении цены и просто обновлять локальную коллекцию, а не самому переполучать данные с определенным интервалом :) Так что, надеюсь, этот enhancement произойдет:)
Поддерживаю @mvkasatkin Как вариант рассмотрите возможность передавать токен в URL или первым сообщением после открытие сокета.
Кстати, для RestAPI включили CORS, что теперь тоже исключает возможность обращения к апи через браузер (без определенных приседаний). Есть ли в этом смысл? Локальные роботы вполне способны работать внутри браузера с использованием indexedDB, имея при этом визуализацию и отсутствие необходимости тянуть за собой и поддерживать излишний бэкенд. Но на данный момент CORS и WebSocket header auth мешают этому, без видимых на то причин. Было бы здорово, если данный вопрос будет решен.
@mvkasatkin cors всегда включены были, но они именно включены, т.е. разрешены. Иначе сваггер бы не работал
@NikitaMelnikov стоит ли ожидать альтернативный способ передачи токена через browser websocket (который не поддерживает кастомные заголовки)?
Пока что не смогли реализовать безопасный способ передачи авторизационных параметров в query. Рекомендую пока что поднять локальный сервер на nodejs и проходить авторизацию через query в нем
@NikitaMelnikov пока так и приходится делать. Но nodejs тут лишь костыль( Очень надеемся, что решение с авторизацией будет найдено. Как вариант, токен может быть передан единоразово, допустим с message auth. Далее на стороне сервера соединение будет считаться авторизованным.
Тоже очень критичная проблема, хотелось бы получить решение. Может как-то связать авторизацию, которая прошла по https, и у вас на сервере на определенное время она будет считаться как пройденной и для websocket ?
Может как-то связать авторизацию, которая прошла по https, и у вас на сервере на определенное время она будет считаться как пройденной и для websocket ?
Из-за технических особенностей такое невозможно
Пробую передать токен следующим образом
Ошибка: Invalid or unexpected token
ws = new WebSocket('wss://api-invest.tinkoff.ru/openapi/md/v1/md-openapi/ws', null, { headers: { Authorization: МОЙ_ТОКЕН}});
Authorization: "Bearer " + token https://tinkoffcreditsystems.github.io/invest-openapi/auth/
@SergeyBruhanov
Браузерный WebSocket принимает 1-2 параметра. И заголовки к нему не добавить. Об этом, собственно, и тред.
В третьем параметре же можно передать любые значения Пробую так
Ошибка: Authentication failed; no valid credentials available
Может дополнительные параметры заголовка не проверяются у Тинькофф ?
@SergeyBruhanov можете посмотреть в DevTools, ваш токен не передаётся на сервер, как и другие не вебсокет заголовки, поэтому и ошибка. Об этом собственно и тред.
JS WebSocket в браузерах не поддерживает передачу заголовков, в отличии от NodeJS, а соответственно, нет возможности передать токен.
Один заголовок все-таки передается - Sec-WebSocket-Protocol. Может в нем передавать, если использование не по назначению этого заголовка не критично со стороны Тинькова?
У разрабов тинькова похоже проблемы с английским - не удостоили даже ответом, поэтому теперь подкидываю ссылку с идеей на русском. Токен отлично передается во втором аргументе - опробовал лично. Задача тиньковских спецов забрать его из Sec-WebSocket-Protocol и провести его авторизацию. Итак, вопрос: что мешает немного откостылить ваш бэкенд? Web socket прокси на node js как пятое колесо в телеге...
Коллеги и разработчики! Зачем нужна авторизация для получения общедоступных данных (стакан, свечи, статус)?
Коллеги и разработчики! Зачем нужна авторизация для получения общедоступных данных (стакан, свечи, статус)?
Потому что. Меня тоже этот вопрос беспокоит. Как и стабильность работы вебсокета. Бывает, что соединение висит, а сообщения перестают приходить. Приходится вешать таймер и перезапускать соединение. И все снова начинает доставляться
Коллеги и разработчики! Зачем нужна авторизация для получения общедоступных данных (стакан, свечи, статус)?
А с чего вы решили, что realtime-данные общедоступные?
Если по делу, то попробуйте распределить подписки по доступным 6 соединениям на пользователя и организовать на своей стороне keep-alive, reconnect + resubscribe (в случае потери связи). Более года все работает стабильно 99.9% времени.
Коллеги и разработчики! Зачем нужна авторизация для получения общедоступных данных (стакан, свечи, статус)?
Такие данные как правило отдаются только с ключами API, и\или авторизацией. Просто так данные не возможно отдавать, дабы существуют на линии дорогостоящие проекты, которые будут висеть на шаре, которые будут топить канал... таких вариантов масса.
Зачем нужна авторизация для получения общедоступных данных
Авторизация нужна, так как мы не имеем право транслировать котировки неопределенному кругу лиц. Только своим клиентам.
