AZ
и пока мы не знаем кто точно отправил запрос хуку - не можем передать эти данные
Size: a a a
2019 February 25
FC
он увидит то, что пользователь сообщит навыку - а это конфиденциальная информация. При входе в навык наш сервак выдает токен, который может "многое", и вот чтобы токен не попал кому-то левому я и спрашиваю как можно уберечься от такого сценария
Наверное, вам пытаются подсказать, что чтобы получить этот токен, нужно быть Яндексом, так как от Алисы запросы шлёт он. Чтобы прикинуться Яндексом и получить данные пользователя, вам нужно знать id девайся, с которого юзер сидит, id юзера. Эти данные вы можете получить только из внутренней бд Яндекса, так как между навыками эти идентификаторы отличаются.
🚀
Всем привет! Вопрос больше к модераторам и разработчикам Алисы, но может у кого есть идеи - помогайте:
Можно ли получить пул ip адресов, с которых яндекс приходит на наш хук или какую-то маску подсети. Ну и возможно ли подписывать запросы, что они точно от яндекса? Мы боимся, что кто-то подберет наш хук и сможет отправлять на него запросы , а проверить яндекс это или нет сейчас невозможно...
Можно ли получить пул ip адресов, с которых яндекс приходит на наш хук или какую-то маску подсети. Ну и возможно ли подписывать запросы, что они точно от яндекса? Мы боимся, что кто-то подберет наш хук и сможет отправлять на него запросы , а проверить яндекс это или нет сейчас невозможно...
используйте 2фа - вот счастье будет
GF
Наверное, вам пытаются подсказать, что чтобы получить этот токен, нужно быть Яндексом, так как от Алисы запросы шлёт он. Чтобы прикинуться Яндексом и получить данные пользователя, вам нужно знать id девайся, с которого юзер сидит, id юзера. Эти данные вы можете получить только из внутренней бд Яндекса, так как между навыками эти идентификаторы отличаются.
именно
🚀
например на базе google authenticator
СА
пока нет правил как это читать, она будет читать по своему. к бабке не ходи будет читать по другому со временем. кроме как периодическими тестами, думаю отловить это не удастся.
в целом так, да..только мониторить и править
🚀
закрываться по айпи смысла нет, т.е. колонка суть интерфейс и в широком смысле ей пользуется кто угодно и шлет вам что угодно, просто через колонку
🚀
если боитесь подделки запроса просто не принимайте второй раз с одним ключом например, достаточно большой ключ и вшитая дата-время в генерацию решит проблему пересечений
ИЛ
это к чему?
пользователь навыка и так подтверждает все паролем из смс, второй фактор есть. Дело в том что все идет через хук, на который может прийти не только яндекс.
Говоря о конфиденциальной информации я не имею ввиду данные пользователя в алисе, юзер айди и тд.
Это его реальные конфиденциальные данные (личные, как паспорт) которые он передает навыку при его использовании
пользователь навыка и так подтверждает все паролем из смс, второй фактор есть. Дело в том что все идет через хук, на который может прийти не только яндекс.
Говоря о конфиденциальной информации я не имею ввиду данные пользователя в алисе, юзер айди и тд.
Это его реальные конфиденциальные данные (личные, как паспорт) которые он передает навыку при его использовании
СА
закрываться по айпи смысла нет, т.е. колонка суть интерфейс и в широком смысле ей пользуется кто угодно и шлет вам что угодно, просто через колонку
вот именно, какая разница то - кто то найдет ваш урл хука, либо обратится к этому урлу через яндекс?
🚀
ну человек думает что ip хороший выбор ограничить источники запросов
AZ
это к чему?
пользователь навыка и так подтверждает все паролем из смс, второй фактор есть. Дело в том что все идет через хук, на который может прийти не только яндекс.
Говоря о конфиденциальной информации я не имею ввиду данные пользователя в алисе, юзер айди и тд.
Это его реальные конфиденциальные данные (личные, как паспорт) которые он передает навыку при его использовании
пользователь навыка и так подтверждает все паролем из смс, второй фактор есть. Дело в том что все идет через хук, на который может прийти не только яндекс.
Говоря о конфиденциальной информации я не имею ввиду данные пользователя в алисе, юзер айди и тд.
Это его реальные конфиденциальные данные (личные, как паспорт) которые он передает навыку при его использовании
пользователь у вас на сервисе получает одноразовый код, сроком 5 минут...
вводит его в алисе
вы по сессии отпределяете юзера и храните авторизацию у себя... userid разные для каждого отдельного экземпляра приложения (навыка) и устройства
вводит его в алисе
вы по сессии отпределяете юзера и храните авторизацию у себя... userid разные для каждого отдельного экземпляра приложения (навыка) и устройства
🚀
по мне так отгородиться не получится
🚀
в общем вам нужны куки для веб-сессии, по факту userid подходит
🚀
а начальная авторизация по 2 факторке
ИЛ
в общем вам нужны куки для веб-сессии, по факту userid подходит
Можете описать как это поможет?
🚀
ну пользователь 1 раз авторизуется, вы привязываете его userid к себе и дальше "доверяете" ему в рамках какого-то временного фрейма - час например или до 5 минут бездействия
🚀
userid не передается через гет запрос в составе урла, идет постом, в теле
🚀
одна неприятная особенность - иногда слетает при обновлениях
KT
Вопрос не в том, насколько возможно подобрать "секретный" ключ в url хука. А в том, как он хранится.