Oauth yandex ru что это

Автоматизация Яндекс.Директ. Часть 1

Совместно с коллегами из ADF Media — Артемом Дурневым и Султаном Назаралиевым, мы решили выпустить цикл из 6 статей, посвященных автоматизации процессов в Яндекс Директе. Сегодня вас ждет вступительная часть, в которой мы поговорим про API, токены Директа и Песочницу.

Чтобы автоматизировать работу Я.Директа, мы должны понимать, что такое API.

API — это составляющая часть сервиса, которая позволяет отправлять запросы и получать ответы.

Единого сценария работы с API нет. У каждого сервиса — сценарий свой. Единственное общее — это токены. Не важно с какой рекламной площадкой вы работаете, в любом случае вам нужно будет получать токен.

Токен — это «ключ» к сервису. Где-то токены нужно получать каждый час, а где-то вы должны владеть двумя «токенами» и передавать их на сервер, чтобы получать «истинный» токен в зашифрованном виде. А где-то вы просто получаете от системы один токен и пользуетесь им продолжительное время.

Так как мы говорим про Яндекс, то в нем получение токена организовано по принципу OAuth. Срок действия токена — один год.

OAuth — это протокол авторизации. Например, получив токен, вы можете передать его любому человеку для авторизации в сервисе, которым пользуетесь. Ему не нужно будет знать ваш логин и пароль, если у него есть токен.

Та же история с Я.Директом. Если вы передадите токен, человек сможет управлять рекламными кампаниями и скачивать данные из статистики за вас.

Токен Яндекс.Директа выглядит следующим образом:

Казалось бы, что это просто набор цифр и букв, но на самом деле каждый такой токен содержит следующую информацию:

• идентификатор учетной записи, к которой разрешен доступ;
• идентификатор приложения, которому разрешен доступ;
• набор прав (действий, доступных приложению).

Таким образом, токен показывает, что может делать данное приложение от имени определенного аккаунта.

Есть два варианта получения токена. Простой и сложный. Сложный заключается в том, что нам необходимо стать разработчиком и зарегистрировать приложение. Делается это следующим образом:

1. Регистрируемся на сервисе Яндекс.OAuth
2. Создаем заявку на доступ к API

Указываем название приложения. В описании можно указать для чего создается приложение.

В графе «платформы” указываем веб-сервисы и нажимаем “Подставить URL для разработки».

Далее необходимо указать какие доступы мы можем запрашивать токеном.

После пройденных шагов, вы получите ID и пароль приложения.

После регистрации OAuth приложения нужно подать заявку на доступ к API Яндекс.Директ. Для этого заходим в Яндекс.Директ и переходим во вкладку API, как показано ниже.

Далее открываем «Мои заявки»

Смело нажимаем на «Полный доступ» и заполняем поля. Вот как заполнили мы:

В демо-доступе указали ссылку на Google Таблицу.

Срок рассмотрения заявки до 7 дней, но, как правило, рассмотрение занимает один-два дня. После этого заявка будет одобрена или отклонена. Как только приложение будет одобрено, вы сможете «вытаскивать» токены.

Переходим по ссылке вида:

(Не забудьте, поменять хвостик, заменив его на свой ID, который получили выше)

И в ответ на наш запрос — получаем токен.

Простой способ получения токена — Переходим на сайт ADF-media и авторизовываемся. В ответ на авторизацию, сайт покажет вам ваш токен.

Давайте сделаем первую часть цикла статей максимально полезной и поговорим еще и про Песочницу. Пока поверхностно, чтобы иметь о ней минимально представление.

Песочница — это среда для отладки приложений, взаимодействующих с API Директа.

Песочница имитирует API Директа, но полностью изолирована от настоящих данных. Это «игровая площадка», на которой можно вызывать методы API, получать ответы, наблюдать изменение тестовых кампаний и объявлений. Действия, которые доступны в API только при положительном балансе, в Песочнице доступны без фактического внесения средств.

Запросы к Песочнице не изменяют данные в Директе. Созданные объявления нигде не показываются, а списываемые и зачисляемые средства не влияют на настоящие кампании. Однако для кампаний имитируется полный набор состояний — от модерации до остановки показов при исчерпании средств. Статистические отчеты хотя и содержат условные данные, но по структуре совпадают с настоящими отчетами. Это делает Песочницу полнофункциональной средой для отладки приложений.

Песочница не имеет веб-интерфейса, и посмотреть тестовые кампании в интерфейсе невозможно. Работать с Песочницей можно только через вызовы методов API.

Но нужно помнить, что:

• В песочнице действуют те же ограничения, что и в API.
• В сервисе Reports можно запросить данные только по одной кампании в каждом отчете.
• Данные в песочнице хранятся в течение месяца со дня последнего обращения к ним, после чего удаляются.

Мы знаем, что такое API, как зарегистрировать приложение и зачем это нужно, а также понимаем, что такое Песочница.

в следующей статье, мы воспользуемся полученными знаниями для передачи первых данных из Яндекс.Директа в Google Таблицы (без знания программирования).

1234ru / Yandex.Oauth.md

Токен не существует сам по себе, а выдается приложению от имени чьего-то аккаунта в Яндексе. Таким образом владелец аккаунта разрешает этому приложению доступ к определенным операциям со своим аккаунтом. Токен является реализацией такого разрешения.

1. Регистрируем приложение

Заполняем форму на https://oauth.yandex.ru/client/new. Обязательно сделать следующее:

• указать название приложения (например, «watches.ru site engine»)
• в разделе Callback URI нажать «Подставить URL для разработки», в поле возникнет адрес от Яндекса
• среди доступов найти нужный раздел (например, для Яндекс.Маркета и Беру.ру это Яндекс.Маркет).

После отправки формы отобразится страница с параметрами приложения, отсюда нужно взять его идентификатор и пароль.

В дальнейшем доступ к этим данным осуществляется по адресу https://oauth.yandex.ru/client/<id приложения> . Страница будет доступна только тому аккаунту, от имени которого было создано приложение (создать приложения без аккаунта в Яндексе нельзя).

2. Разрешаем приложению доступ — получаем токен

Заходим на Яндекс с учетной записью пользователя, к аккаунту которого приложение должно запросить доступ. (Он может отличаться от аккаунта, из-под которого было создано приложение, но может и совпадать.)

Взять идентификтор приложения, подставить его в адрес
https://oauth.yandex.ru/authorize?response_type=token&client_id=<идентификатор приложения>
и открыть страницу. Нажать Разрешить.

Прямо на странице будет отображен новый токен. Его нужно куда-то сохранить, т.к. как его посмотреть потом — пока неизвестно. А в адресе в параметре expires — время жизни в секундах (например, для приложения с доступом к Яндекс.Маркету это один год).

3. Отправляем токен с HTTP-запросами

В состав запросов токен включается с помощью заголовка Authorization: Oauth , куда входит также идентификатор приложения:

OAuth на практике. Аутентификация и авторизация пользователей сайта через популярные социалки

Потому что OpenID практически бесполезен для тех целей, для которых декларирован. Это сугубо мое мнение, но оно опирается не на пустое место.
Во-первых, OpenID пользуются в основном «гики», процент которых в интернете не настолько высок, чтобы перестраивать под них сайты (за некоторым исключением, разумеется 🙂 ) Почему так? Потому что для того, чтобы получить OpenID аккаунт, надо — его получить. Зайти на OpenID сервер и предпринять некоторые действия, чтобы заполучить некий, довольно невразумительный, набор символов. Который, несмотря на сложность (для простого пользователя) надо не забыть и вводить при случае, если на глаза попадется знакомая пиктограмма . Ну какой казуальный пользователь будет это делать? А с OAuth все намного проще — видит человек кнопку «Войти через ВКонтакте», нажимает, и… уже на сайте с правами зарегистрированного пользователя. «Будьте проще», — говорил классик, — «и люди к вам потянутся». Как в воду глядел.
Во-вторых, возможности OAuth далеко не исчерпываются аутентификацией и авторизацией. Получив в процессе авторизации токен, его можно использовать для дальнейшей интеграции возможностей социалки в свой ресурс — чтение/написание постов, доступ к френдленте и стене и многое другое.
В-третьих, OpenID активно пользуются спамеры и хакеры. Зачастую реализация OpenID аутентификации на ресурсе делается без особого внимания к известным его уязвимостям — по одному только описанию протокола на OpenID-провайдере или с помощью неизвестно кем и когда написанной библиотеки. К примеру, многие сайты не требуют со входящих по OpenID ввода капчи. И ничто не мешает злоумышленнику поднять свой OpenID-сервер, который будет подтверждать любой идентификатор и начать спамить доверчивый сайт автоматически сгенеренными идентификаторами. Кроме того, OpenID аутентификация, в сущности, не дает никаких гарантий клиенту. Она подтверждает лишь, что запрашиваемый пользователь действительно зарегистрирован на одном из OpenID-серверов — и все. Механизмы получения дополнительной информации о пользователе (email, имя, возраст) имеются, но мало кем поддерживаются. Можно, конечно, в нарушение идей OpenID, анализировать идентификатор и доверять только определенным OpenID-провайдерам (например, тем же социалкам). Но смысл, если почти все из них (за исключением ЖЖ, но он и по OpenID ровным счетом ничего не расскажет о пользователе) поддерживают OAuth, который позволяет получить намного больше информации? Так что со всех своих сайтов я вообще убрал поддержку OpenID.

Почему OAuth, а не виджет «Войти через»?

Нет проблем. Если вас устраивают функционал, дизайн и уровень безопасности виджета — то его воткнуть в код на самом деле намного проще — можете дальше не читать.

Как это работает.

1. Заходите на сервис-провайдер ХХХ, регистрируете там свой сайт, получаете код клиента и секретный код.
2. По нажатию кнопки на вашем сайте «войти через ХХХ» производится обмен запросами с сервером XXX, перенаправление пользователя на ХХХ для ввода пароля, логина и подтверждения передачи данных на ваш сайт и получения токена, с помощью которого у сервера ХХХ можно запросить дополнительные данные о пользователе. Конкретика зависит от реализации OAuth на сервис-провайдере — поддерживаемой версии протокола, поддерживаемых потоков и пр.
3. С помощью полученного токена с сервера ХХХ получаются имя, емайл, дата рождения, аватар и прочая информация, которая обычно и требуется при регистрации. После этого можно вызывать стандартную функцию по добавлению нового пользователя.

Почему сырой HTTP, а не куски кода с использованием OAuth библиотеки?

Потому что я порядком помучался, вытаскивая этот самый сырой HTTP зачастую и из кусков кода, иллюстрирующих использование той или иной библиотеки. Конкретная реализация OAuth на каждом сервере имеет свои тонкости, перед которыми может спасовать даже самая гибкая библиотека. Кроме того, веб-языков много, библиотек — еще больше, дать примеры на все просто нереально. А сырого HTTP (при наличии мозгов) вполне достаточно для использования любой библиотеки. Чего не скажешь об обратном случае.

Практические рекомендации по реализации

Разумеется, в первую очередь надо зарегистрироваться в соцсети, активировать аккаунт, ну и всё такое. Не торопиться. Некоторые сервера не сразу корректно обрабатывают запросы от свежезарегистрированных OAuth-клиентов. Здесь я расписал только успешные потоки, забывать про обработку ошибок — никак не стоит. Также я практически не уделил внимания аспектам безопасности — это тема отдельной статьи. Как минимум, везде, где можно передавать уникальный параметр в callback-url для каждого пользователя — это стоит делать (Основной callback адрес должен оставаться без изменений, а меняться — только параметр, иначе сервер не пропустит запрос. Особо обратите на это внимание, если у вас стоит mod_rewrite), как и пользоваться параметром state для передачи дополнительных данных callback-скрипту (там, где этот параметр поддерживается). Я все это пока оставил за скобками.

ВКонтакте

1. Идем сюда. Тип — «Веб-сайт». Вводим базовый домен и адрес сайта. На странице настроек получаем client_id (ID приложения) и secret_key (защищенный ключ). 2. Втыкаем в код кнопку вида Почему response_type=code, а не token? Потому что некоторые ресурсы не поддерживают response_type=token. Что такое vklogin? Это скрипт, который должен будет обработать ответ от сервера ВКонтакте, получить от него токен и добыть информацию о пользователе.
3. Что делает vklogin?
3.1. vklogin получает в get-параметрах (прямо в строке запроса) результаты авторизации. В случае успеха

3.4. В ответ на это (опять же в случае успеха) мы получаем опять-таки JSON список перечисленных параметров. Что нам и нужно было. Имя пользователя — в utf8, город и регион — в виде кодов, названия надо получать вызовом отдельного метода с укаазнием кода.
Полный список того, чего можно запросить, можно взять здесь. Полный список методов API ВКонтакте здесь.

Одноклассники

1. Регистрируемся как разработчик здесь. Идем сюда и заполняем заявку на получение OAuth доступа. Н-да. Заявка, похоже, обрабатывается вручную. Если ответа в течение суток нет, пинаем поддержку по тому же адресу. «Одноклассники», что тут скажешь.
2. Получаем письмо с инструкциями и, следуя им, заполняем форму.
Все заполненные в примере поля обязательны к заполнению. Нажимаем «Сохранить» и получаем письмо на указанный емайл, содержащее client_id(Application ID), public_key(Публичный ключ приложения) и secret_key(Секретный ключ приложения)
3. Код кнопки должен быть вида: 4. oklogin
3.1. Анализируем строку на наличие code.
3.2. Выполняем POST запрос на:

Да-да, часть подписи кодится дважды.
3.4. В ответ получаем JSON-список параметров, содержащий имя, ссылку на фото, день рождения и пр. Имя — utf8;
Полный список возвращаемых параметров функции users.getCurrentUser здесь. Описание API здесь. Но сразу предупреждаю, что автор его был болен рассеянным склерозом в последней стадии, поэтому о многих аспектах использования той или иной функции надо просто догадываться.

Facebook

1. Идем сюда и нажимаем «Создать новое приложение». В настройках в пункте App Domains вводим наш(и) домен(ы). Ставим галочку на «Website with Facebook Login» и вводим url нашего сайта. Записываем client_id (App ID) и secret_key (App Secret).На вкладке «Auth Dialog» ставим галочку на «Authenticated Referrals» и тип «code» в «Auth Token Parameter».
2. Кнопка на нашем сайте отправляет пользователя на:

3.4. В ответ получаем JSON-список параметров, содержащий имя, ссылку на фото, день рождения и пр. Имя — NFC юникод (в виде \u0410\u0401\u0419)
Список функций API (и возвращаемых данных) здесь.

Twitter

1. Идем сюда и регаем новое приложение. Вводим имя, описание, наш сайт и урл скрпита-обработчика. На странице настроек нажимаем кнопку «Create my access token».

Дальше слов нет, сплошные эмоции. Горечь и боль переполняют меня. Ну зачем же они так. Рекомендую для начала натравить на twitter какую-нибудь OAuth-библиотеку. И только, если ничего не получится (лично у меня не получилось подружить Net::OAuth с твиттером) вооружаемся терпением и лезем разбираться.

1. Здесь OAuth 1.0 и тут всё веселее. При нажатии пользователем кнопки «Зайти через Twitter» мы запускаем скрипт, который выполняет POST-запрос на

3.4. В случае успеха нам приходит JSON-список параметров, содержащий имя, фото и пр. Полный список функций API и их описания здесь.

Mail.ru (МойМир)

1. Идем сюда и регистрируем сайт. Вводим название, урл сайта и урл файла receiver.html, который можно скачать тут же. receiver.html — файл, инициализирующий JS API, и, в нашем случае он не нужен, но сервер МайлРу проверяет наличие этого файла по указанному адресу и не дает закончить регистрацию, пока этот receiver.html не окажется там, где полагается. На странице настроек получаем client_id (ID) и secret_key (секретный ключ).2. Код кнопки должен быть вида: 3. mmlogin
3.1. Анализируем строку на наличие code.
3.2. Выполняем POST запрос на:

в виде hex string.
3.4. В ответ получаем JSON-список параметров, содержащий имя, ссылку на фото, день рождения и пр. Имя — utf8;
Список функций API (и описания) здесь.

Яндекс

1. Идем сюда. Выбираем все права Яндекс.логин. Вводим параметры.
Получаем client_id(Id приложения) и secret_key(Пароль приложения).
2. Код кнопки должен быть вида: 3. yalogin
3.1. Анализируем строку на наличие code.
3.2. Выполняем POST запрос на:

чего не наблюдалось в ответах от других сайтов. Тут явно ошибка библиотеки, RFC на JSON не запрещает лишние пробелы, но на всякий случай обращаю внимание — вдруг кто-то еще споткнется на этом.
Описание API yandex.login здесь.

Google

1. Идем сюда. Создаем новый проект. На вкладке API access нажимаем кнопку «Create an OAuth2 client ID».Получаем client_id(Client ID) и secret_key(Client Secret).
2. Код кнопки должен быть вида: 3. gglogin
3.1. Анализируем строку на наличие code.
3.2. Выполняем POST запрос на:

3.4. В ответ получаем JSON-список запрошенных параметров.
Описание API работы с гугл-контактами здесь.

На этом пока все. Думаю, даже самые нелюдимые пользователи рунета имеют аккаунт хотя бы на одном из вышеупомянутых серверов.
Надеюсь, статья поможет тем, кто хочет сделать на своем сайте регистрацию по OAuth. Во всяком случае, попадись мне такая статья раньше, я бы сэкономил кучу времени и сил.
Я реализовывал это всё на perl, соответственно, если у кого возникнут вопросы по реализации OAuth на перле — могу дать свои рекомендации. По другим языкам — увы.

Oauth yandex ru что это

Сегодня мы подробно разберем процесс получения OAuth-токена для доступа к Яндекс.Директ API. Впервые сталкиваясь с процессом получения токена, будь-то API от Google или Яндекса, я по-началу терялся в заявках, регистрациях и прочей бюрократической вакханалии. Поэтому я, буквально, за руку проведу тебя к заветному апи-токену, который мы сразу и проверим.

Как следует из справки Яндекс.Директ API, вся процедура делится на два этапа:

• Регистрация на сервисе Яндекс.OAuth
• Создание заявки на доступ к API

Регистрируем приложение в Яндекс.Директ API

Авторизуемся из под аккаунта с кабинетом Яндекс.Директ, данные которого нас интересуют. Переходим на страницу oauth.yandex.ru, и жмем на желтую кнопку «Зарегистрировать новое приложение». И заполняем поля, согласно плану:

• Название приложения*: DirectDataDealer
• Описание приложения: Необязательное. Но я всё таки напишу: Приложение для пробросаданных в системы сквозной аналитики
• Иконка приложения: Необязательное.
  
• Ссылка на сайт приложения: Необязательное.
• Платформы: Веб-сервисы и в поле Callback Url жмем Подставить URL для разработки.
• Доступы*: Яндекс.Директ -> Использование API Яндекс.Директа

Отлично, приложение создано, на выходе получится что-то похожее на это:

Отлично, пол дела сделано, осталось запросить доступ к API.

Создаем заявку на доступ к Яндекс.Директ API

Теперь создадим заявку, тут всё довольно просто. Идём сюда и создаем заявку на доступ. Начинаем заполнять:

• Введите application_id или выберите из списка * : В дропменю выбираем наше приложение в моём случае это DirectDataDealer.
• Укажите один или несколько контактов, по которым с вами быстро сможет связаться служба поддержки*: Пишем ваш мейл.
• Данные о компании: Скорее всего у вас или у вашего клиента уже есть сайт, в моем случае Akulshin.ru и https://akulshin.ru/
• Выберите утверждение, которое лучше всего описывает специфику вашей работы. Вы:* Я прямой рекламодатель, а вы?
• Технические данные о приложении: Язык программирования — Python, протокол — Json, версия библиотек — 3.8. В примерах из моих статьей используются именно эти версии.
  
• Для примера успешной работы приложения, укажите один или несколько логинов в Директе, для которых оно используется *: Абсурд, если вы регистрируете своё первое приложение, то просто укажите текущий логин в Яндексе.
  
• Для чего предназначено приложение*: В моем случае это — Синхронизировать рекламные материалы с данными внутренних систем (товары, деньги, отчетность)
• Основные функции приложения*: Получение статистики и отчетов
• Какие новые возможности работы с Директом дает ваше приложение пользователям?*: Я написал, что «Агрегирую данные в сквозной аналитике и предикторе. Получение статистики Яндекс.Директ и её дальнейшая обработка.»
• Опишите схему взаимодействия вашего приложения с Директом*: Программа запускается автоматически 2 раза в сутки, в основном используем метод «AccountManagement» и сервис Campaign для получения статистики, далее передаем в базу, где обрабатываем.
• Спецификации, скриншоты интерфейса * : Либо нарисуйте блок-схему обработки данных, либо как я заскриньте IDE, пусть какому-нибудь модеру из Яндекса станет за вас стыдно.
• По возможности предоставьте нам демо-доступ к программе: Игнорируем этот пункт

Бум! Всё готово, отправляем на рассмотрение. После прохождения, в итоге получим такую картину:

Получаем OAuth-токен Яндекс.Директ:

Существует 2 способа получения API-токена: Ручной и Автоматический

Так как мы не пишем приложение, которое будут использовать десятки авторизованных пользователей, то нам хватит и ручного получения токена. Теперь дело за малым, делаем запрос на выдачу «API-ключа», который мы будем использовать в нашем приложении. Для этого: