Токен к api

Avatar
  • обновлен
  • Отвечен

Как получит токен для API zenmoney? В каком парметре его передавать или в каком заголовке? Приведите минимальный пример запроса на транзакции.

Прикрепленные ответы
Avatar
skvav
  • Ответ

Для начала нужно зарегистрировать клиентское приложение. Тут, по нажатию на "скриптом"

http://developers.zenmoney.ru/index.html

После этого используем полученные consumer_key, consumer_secret и введенный OAuth callback point url в качестве client_id, client_secret и redirect_uri протокола OAuth 2.0. Дальнейшее взаимодействие и доступные методы API описаны тут:

https://github.com/zenmoney/ZenPlugins/wiki/ZenMoney-API

Avatar
Maksim Slotin

Всем привет!

Совсем не силен в AOuth2, библиотека выложенная на гитхабе не позволяет пройти авторизацию и выгрузить данные. Мучаюсь уже несколько дней...

Если у кого-то есть возможность поделиться готовым кодом на питоне, в рамках которого вставив свои credentials я смогу что-то выгрузить из API, то был бы очень благодарен. Моя страница вк: Мессенджер (vk.com), моя почта: mslotin@nes.ru

Avatar
Dmitry Shanko
Цитата от skvav

Порядок параметров не важен, это вы что-то неправильно делаете. Поддерживается как и x-www-form-urlencoded так и json.

Кука нужна для авторизации, реализация страницы авторизации - внутреннее дело сервера, и по стандарту не должна учитываться клиентом OAuth, так как может меняться. Дело клиента перенаправить на /oauth2/authorize/ и ждать редиректа :)

Порядок тем не менее имеет значение, насчет application/json не проверял (согласно предыдущим ответам в этой ветке нужно было использовать только x-www-form-urlencoded).

Кука тоже обязательна, она учитывается, хотя не должна.

"Дело клиента перенаправить на /oauth2/authorize/ и ждать редиректа :)" - Вы насильно заставляете клиент использовать то решение, которые Вы сделали, но стандарт OAuth значительно более гибок, чем текущая реализация.

Avatar
skvav
Цитата от Dmitry Shanko

Серьезно?) Скажите, пожалуйста, есть ли в мире хоть один сервис, где от порядка параметров в запросе (при условии что сервис не использует какое-либо кодирование тела/параметров ключами) зависит результат?)

А вот при отправке сюда с типом "application/x-www-form-urlencoded'" (серьезно? такое еще используется?)

curl --location --request POST 'https://api.zenmoney.ru/oauth2/token/' \--header 'Content-Type: application/x-www-form-urlencoded' \

оказывается важен порядок параметров grant_type, client_id, client_secret, code, redirect_uri.

К тому же джсон тело запроса - это для начала контент-тайп application/json, а не то, что используется по факту.


Скажите, пожалуйста, на что влияет кука zen_AU при подтверждении логина OAuth (POST https://api.zenmoney.ru/oauth2/authorize/)? Или просто разработчики решили наказать пользователей/забыли убрать? Архитектурно она не нужна, т.к. это действие не требует наличия логин-сессии. Выглядит как костыль, который воткнули, просто чтобы было.

Порядок параметров не важен, это вы что-то неправильно делаете. Поддерживается как и x-www-form-urlencoded так и json.

Кука нужна для авторизации, реализация страницы авторизации - внутреннее дело сервера, и по стандарту не должна учитываться клиентом OAuth, так как может меняться. Дело клиента перенаправить на /oauth2/authorize/ и ждать редиректа :)

Avatar
Dmitry Shanko

На самом деле очень печально, что нету REST API для работы с пользовательскими сущностями. Де-факто это уже стандарт индустрии последние 5 лет минимум.

Avatar
Dmitry Shanko
Цитата от skvav

В чем жесть? :) Обычные наистандартнейшие json запросы, пишутся за 10 секунд.

Серьезно?) Скажите, пожалуйста, есть ли в мире хоть один сервис, где от порядка параметров в запросе (при условии что сервис не использует какое-либо кодирование тела/параметров ключами) зависит результат?)

А вот при отправке сюда с типом "application/x-www-form-urlencoded'" (серьезно? такое еще используется?)

curl --location --request POST 'https://api.zenmoney.ru/oauth2/token/' \--header 'Content-Type: application/x-www-form-urlencoded' \

оказывается важен порядок параметров grant_type, client_id, client_secret, code, redirect_uri.

К тому же джсон тело запроса - это для начала контент-тайп application/json, а не то, что используется по факту.


Скажите, пожалуйста, на что влияет кука zen_AU при подтверждении логина OAuth (POST https://api.zenmoney.ru/oauth2/authorize/)? Или просто разработчики решили наказать пользователей/забыли убрать? Архитектурно она не нужна, т.к. это действие не требует наличия логин-сессии. Выглядит как костыль, который воткнули, просто чтобы было.

Avatar
skvav
Цитата от Dmitry Shanko

А можно как-то попроще сделать? Окей, получение кода клиента OAuth согласно спецификации требует редирект_урл, тут без вопросов. Но какая же жесть идет следом по получению токена. На дворе 2021 год, все пользуются РЕСТ сервисами, а не шлепают формы по отправке данных.

Извините, накипело, больше часа вспоминал особенности форматирования данных при отправке формы через постман.

И впереди еще несколько часов на преобразование этого формошлепства в хттп запрос в коде самого приложения.

В чем жесть? :) Обычные наистандартнейшие json запросы, пишутся за 10 секунд.

Avatar
Dmitry Shanko

А можно как-то попроще сделать? Окей, получение кода клиента OAuth согласно спецификации требует редирект_урл, тут без вопросов. Но какая же жесть идет следом по получению токена. На дворе 2021 год, все пользуются РЕСТ сервисами, а не шлепают формы по отправке данных.

Извините, накипело, больше часа вспоминал особенности форматирования данных при отправке формы через постман.

И впереди еще несколько часов на преобразование этого формошлепства в хттп запрос в коде самого приложения.

Avatar
skvav
Цитата от renatuvarov1311

делаю запрос на получение токена:
curl --location --request POST 'https://api.zenmoney.ru/oauth2/token/' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'grant_type=authorization_code' \
--data-urlencode 'client_id=id' \
--data-urlencode 'client_secret=secret' \
--data-urlencode 'code=КОД ИЗ КУКИ zen_AU' \
--data-urlencode 'redirect_uri=http://localhost/callback'

ответ: "error": "invalid_grant"
в чем может быть причина?

Пожалуйста, читайте документацию. Кука тут не причем. Код надо брать из параметров редиректа.

Avatar
Цитата от renatuvarov1311

делаю запрос на получение токена:
curl --location --request POST 'https://api.zenmoney.ru/oauth2/token/' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'grant_type=authorization_code' \
--data-urlencode 'client_id=id' \
--data-urlencode 'client_secret=secret' \
--data-urlencode 'code=КОД ИЗ КУКИ zen_AU' \
--data-urlencode 'redirect_uri=http://localhost/callback'

ответ: "error": "invalid_grant"
в чем может быть причина?

чуть выше на этой странице уже есть обсуждение ошибки invalid_grant. Вы читали тот пост? Возможно у вас такая же проблема. Судя по всему эта ошибка происходит в том случае, если запросы authorize и token содержат разные параметры. В моем случае беда была из-за того, что я в этих запросах указывал разные значения для redirect_uri.

Avatar
renatuvarov1311

делаю запрос на получение токена:
curl --location --request POST 'https://api.zenmoney.ru/oauth2/token/' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'grant_type=authorization_code' \
--data-urlencode 'client_id=id' \
--data-urlencode 'client_secret=secret' \
--data-urlencode 'code=КОД ИЗ КУКИ zen_AU' \
--data-urlencode 'redirect_uri=http://localhost/callback'

ответ: "error": "invalid_grant"
в чем может быть причина?