Не передан идентификатор приложения в параметре client id

Mail.Ru API

Вы можете подключить авторизацию от Mail.Ru к любому сайту. Вы можете использовать полученный идентификатор сессии для регистрации или логина пользователя на вашем сайте, а также для доступа к REST API Mail.Ru.

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

Обзор процесса авторизации сайта

Авторизация реализована по протоколу OAuth 2.0. Подробнее о деталях реализации OAuth в Mail.Ru и использовании его для доступа к API читайте в руководстве по авторизации.

Для запуска процесса направьте пользователя на страницу авторизации, задав адрес страницы на вашем сайте, на которую пользователь будет направлен после авторизации.

Когда пользователь авторизует ваш сайт, его браузер будет отправлен на заданный вами адрес. Используйте параметры в URL страницы чтобы получить идентификатор сессии.

Детальное описание процесса авторизации

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

В нужный момент, сделайте редирект на страницу авторизации. Например, вы можете сделать кнопку «Войти с Mail.Ru» на страницах регистрации или логина, по нажатию на которую будет происходить перенаправление. Адрес страницы авторизации:

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

В качестве значений параметра response_type вы можете указать одно любое значение из списка (какое значение следует выбрать зависит от того, что вы будете делать с полученными параметрами):

Используйте необязательный параметр scope чтобы запросить у пользователя требующиеся вашему сайту привилегии. Если требуется запросить несколько привилегий, они передаются в scope через пробел.

После авторизации пользователь будет перенаправлен на страницу, указанную вами в redirect_uri, например, http://example.com/oauth/receiver.

Если вы указали response_type=token

После авторизации браузер будет перенаправлен на адрес следующего вида:

На вашей принимающей странице должен быть ваш JavaScript, который при открыти страницы разберет содержимое якоря (части после символа #): оно представлено в формате application/x-www-form-urlencoded.

Значение access_token — это идентификатор сессии, необходимый для работы с REST API.

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

Если вы указали response_type=code_and_token

Этот вариант аналогичен предыдущему, за исключением того, что к возвращаемым параметрам добавляется code, например, так:

Обработайте параметры аналогично варианту с response_type=token и отправьте значение code на сервер для получения отдельной сессии для использования REST API с сервера вашего сайта (подробности см. ниже).

Если вы указали response_type=code

В этом случае результат авторизации выозвращается в виде GET-параметров, чтобы вы сразу имели к ним доступ с сервера, например, так:

Обменяйте полученный авторизационный код на идентификатор сессии, который вы сможете использовать для доступа к REST API. Для этого с сервера сделайте следующий POST-вызов на адрес https://connect.mail.ru/oauth/token:

В теле POST-запроса должны находиться данные в формате application/x-www-form-urlencoded (все указанные параметры обязательны):

В ответ на этот запрос вы получите примерно такой результат:

Значение access_token — это идентификатор сессии, необходимый для работы с REST API.

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

Дополнительно

В случае возникновения ошибок в процессе авторизации, браузер также будет перенаправлен на указанный redirect_uri, с указанием причины ошибки в параметре error. См. подробности в разделе Error Response спецификации OAuth.

Важное замечание по безопасности

Если вы привязываете авторизацию на Mail.Ru к авторизации на вашем сайте, используйте для каждого пользователя уникальный redirect_uri. Иначе становится возможной следующая атака:

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

Источник

Настройка авторизации через Mail.ru

Как настроить авторизацию посетителей сайта через Mail.ru в личном кабинете и для оформления заказа

Если у вас несколько сайтов, то авторизацию нужно настроить отдельно для каждого сайта.

Если авторизация для этого сайта уже включена, перейдите по ссылке «Настройки авторизации».

6 комментариев

Добрый день, устанавливаю всё по инструкции не удаётся войти через mail.ru ловлю ошибку :

” Не указано приложение Не передан идентификатор приложения в параметре client_id “.

Возможно, вы не заполнили поле “ID” в настройках авторизации через Mail.ru.

Заполнил 3 поля которые были полученны при регистрации в mail.ru

Посмотрите, какие сообщения об ошибках появляются в PHP-логе и в консоли браузера в момент возникновения проблемы.

Настроила по инструкции. Два сайта нормально работают, а третий выдает

Магазин

Обратитесь к разработчику приложения.

По рекомендации к предыдущему комментарию (консоль браузера) получила

Сценарий из «https://my1.imgsmail.ru/mail/ru/images/js/my/infotolltip.js?8» был загружен, хотя его MIME-тип («text/html») не является допустимым для JavaScript

Возможно, в теме дизайна вы добавили вызов файла с адресом

По этому адресу ничего нет: ошибка 404. Но, возможно, это никак не связано с работой авторизации.

Важнее посмотреть, почему возникает ошибка 500. Как это сделать.

Источник

OAuth 2.0 Авторизация¶

Получение кода авторизации¶

Пример¶

Ответ¶

Пользователь успешно прошел авторизацию

В случае успешного прохождения авторизации пользователь будет перенаправлен на адрес следующего вида:

Пример

После нажатия на кнопку “отмена” пользователь будет перенаправлен на адрес следующего вида:

Пример

Поля

Ошибка при получении кода авторизации

Получение токена¶

Необходимо указать значения параметров client_id и client_secret в параметрах запроса или Authorization-заголовке (Базовая HTTP-авторизация).

Пример¶

Ответ¶

Токен успешно получен

Поля

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

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

Источник

Аутентификация через Mail.ru

Продолжаем цикл статей, посвящённых созданию аутентификации пользователей через социальные сети и сервисы. Сегодня посмотрим, как осуществить подобный функционал через сервис Mail.ru

Если кто пропустил предыдущие выпуски, то их можно найти по следующим ссылкам:

Заметка. Как и в предыдущих статьях, пример, созданный в данном уроке, предназначен для работы на локальном сервере.

Шаг 1. Добавление нового приложения

Для начала нам необходимо добавить новый сайт в нашу учётную запись сервиса Mail.ru. Сделать это можно пройдя по вот этой ссылке. Для работы примера вам нужно будет самим зарегистрировать новое приложение и ввести собственные параметры.

На открывшейся странице, в первую очередь, соглашаемся с правилами размещения сайтов. Далее заполняем форму:

Далее нажимаем на кнопку “Продолжить” и переходим к следующему шагу. На третьем шаге необходимо скачать файл receiver.html, поместить его в каталог вашего проекта и дать Mail.ru возможность проверить существование данного файла. Поскольку наш пример предназначен для работы на локальном сервере, то мы этого делать не будем. Просто нажимаем кнопку “Продолжить”, и на следующей странице “Пропустить”. Если же вы создаёте пример для приложения работающего на каком-то реальном сервере, то сначала пройдите процедуру проверки наличия файла receiver.html, иначе функциональность вашего примера может быть ограничена.

Итак, после успешного добавления сайта в сервис Mail.ru, нам должно выдастся следующее сообщение со специальными параметрами:

Отсюда мы можем извлечь такие параметры, как `ID` приложения, `Приватный ключ` и`Секретный ключ`. Запишем их в специальные переменные в файле index.php:

Шаг 2. Генерация ссылки для аутентификации

Для генерации ссылки нам потребуется адрес аутентификации и специальные параметры:

С помощью функции http_build_query, передав массив параметров, мы получим чередование ключей и значений, как в url адресе. Итак, генерируем ссылку и выводим на экран:

Тут же, в очередной раз, я воспользовался функцией urldecode. Если этого не сделать, то в сгенерированной ссылке могут появиться закодированные символы слешей, знаков двоеточия и так далее:

Если же мы пропустим данную строку через функцию urldecode, то получим:

Ссылка для аутентификации готова. Если мы сформировали все параметры верно и получили правильный url, то пройдя по ссылке, будем перенаправлены по адресу, указанному в настройках приложения (‘http://localhost/mailru-auth’). Как и в предыдущих случаях (при работе с Вконтакте и Одноклассниками), к этому адресу будет прикреплён специальный параметр code:

Шаг 3. Получение токена

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

Далее нам нужно отправить POST запрос на адрес https://connect.mail.ru/oauth/token, передав перечисленные параметры. В PHP выполнить POST запрос можно с помощью создания curl запроса:

Для того чтобы мы далее могли работать с данными параметрами, декодируем JSON строку с помощью функции json_decode и помещаем данные в массив, передав в качестве второго аргумента true.

Шаг 4. Получение информации о пользователе

Для получения информации о пользователе сформированные параметры нам нужно отправить GET запросом по адресу http://www.appsmail.ru/platform/api:

В результате, если всё было сделано успешно, то получим JSON ответ приблизительно следующего вида:

Шаг 5. Извлечение информации о пользователе

Шаг 6. Что же дальше?

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

После этого, всё что нам осталось сделать, так это создать сессию и поместить в неё информацию о нашем пользователе.

Ещё один рецепт создания сторонней аутентификацией у вас в копилке.

P.S. В комментариях к предыдущим статьям многие просят показать, что делать дальше. Как заполнить базу данных, как организовать полный процесс. Я обязательно расскажу об этом в заключительной части цикла данных статей, а до этого нам предстоит ознакомиться с созданием подобного функционала ещё для нескольких соц сетей и сервисов.

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

Данный урок подготовлен для вас командой сайта ruseller.com
Источник урока: www.ruseller.com
Автор: Станислав Протасевич
Урок создан: 15 Марта 2013
Просмотров: 45320
Правила перепечатки

5 последних уроков рубрики “PHP”

Фильтрация данных с помощью zend-filter

Когда речь идёт о безопасности веб-сайта, то фраза “фильтруйте всё, экранируйте всё” всегда будет актуальна. Сегодня поговорим о фильтрации данных.

Контекстное экранирование с помощью zend-escaper

Обеспечение безопасности веб-сайта — это не только защита от SQL инъекций, но и протекция от межсайтового скриптинга (XSS), межсайтовой подделки запросов (CSRF) и от других видов атак. В частности, вам нужно очень осторожно подходить к формированию HTML, CSS и JavaScript кода.

Подключение Zend модулей к Expressive

Expressive 2 поддерживает возможность подключения других ZF компонент по специальной схеме. Не всем нравится данное решение. В этой статье мы расскажем как улучшили процесс подключение нескольких модулей.

Совет: отправка информации в Google Analytics через API

Предположим, что вам необходимо отправить какую-то информацию в Google Analytics из серверного скрипта. Как это сделать. Ответ в этой заметке.

Подборка PHP песочниц

Подборка из нескольких видов PHP песочниц. На некоторых вы в режиме online сможете потестить свой код, но есть так же решения, которые можно внедрить на свой сайт.

Источник

Приложение запрашивает код

Пользователь разрешает доступ приложению.

Яндекс.OAuth перенаправляет пользователя на адрес, указанный в поле Callback URL при регистрации приложения. Код подтверждения (или описание ошибки) передается в параметре URL перенаправления.

Приложение получает адрес перенаправления и извлекает код подтверждения.

Яндекс.OAuth возвращает токен в теле ответа.

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

Запрос кода подтверждения

Приложение должно направить пользователя на Яндекс.OAuth по следующему адресу:

Идентификатор приложения. Доступен в свойствах приложения (нажмите название приложения, чтобы открыть его свойства).

Уникальный идентификатор устройства, для которого запрашивается токен. Чтобы обеспечить уникальность, достаточно один раз сгенерировать UUID и использовать его при каждом запросе нового токена с данного устройства.

Идентификатор должен быть не короче 6 символов и не длиннее 50. Допускается использовать только печатаемые ASCII-символы (с кодами от 32 до 126).

Подробнее о токенах для отдельных устройств читайте на странице Токен для устройства.

Имя устройства, которое следует показывать пользователям. Не длиннее 100 символов.

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

URL, на который нужно перенаправить пользователя после того, как он разрешил или отказал приложению в доступе. По умолчанию используется первый Callback URI, указанный в настройках приложения ( Платформы → Веб-сервисы → Callback URI ).

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

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

Параметр позволяет помочь пользователю авторизоваться на Яндексе с тем аккаунтом, к которому нужен доступ приложению. Получив параметр, Яндекс.OAuth проверяет авторизацию пользователя:

Если пользователь уже авторизован с нужным аккаунтом, Яндекс.OAuth просто запрашивает разрешение на доступ.

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

Если параметр указывает на несуществующий аккаунт, Яндекс.OAuth сможет только сообщить об этом пользователю. Приложению придется запрашивать токен заново.

Список необходимых приложению в данный момент прав доступа, разделенных пробелом. Права должны запрашиваться из перечня, определенного при регистрации приложения. Узнать допустимые права можно по ссылке https://oauth.yandex.ru/client/ /info, указав вместо идентификатор приложения.

Если параметры scope и optional_scope не переданы, то токен будет выдан с правами, указанными при регистрации приложения.

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

Если параметры scope и optional_scope не переданы, то токен будет выдан с правами, указанными при регистрации приложения.

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

Признак того, что у пользователя обязательно нужно запросить разрешение на доступ к аккаунту (даже если пользователь уже разрешил доступ данному приложению). Получив этот параметр, Яндекс.OAuth предложит пользователю разрешить доступ приложению и выбрать нужный аккаунт Яндекса.

Параметр полезен, например, если пользователь вошел на сайт с одним аккаунтом Яндекса и хочет переключиться на другой аккаунт. Если параметр не использовать, пользователю придется явно менять аккаунт на каком-нибудь сервисе Яндекса или отзывать токен, выданный сайту.

Строка состояния, которую Яндекс.OAuth возвращает без изменения. Максимальная допустимая длина строки — 1024 символа.

Можно использовать, например, для защиты от CSRF-атак или идентификации пользователя, для которого запрашивается токен.

Источник

• через какое время делают повторное эко →