Комментарии 44
Кроме «спасибо» и сказать особо нечего:)
и как его лучше использовать на сайтах
До тех пор, пока он в статусе черновиков — его стоит использовать с осторожностью :-)
Однако в HTML5, который в статусе драфта все нырнули с головой :)
У нас для сайтов есть специальная js-обертка, которая избавляет от проблем с изменением стандарта — api.mail.ru/docs/guides/jsapi/.
Но, в принципе, там все настолько просто, что сильно меняться оно уже вряд ли будет.
Но, в принципе, там все настолько просто, что сильно меняться оно уже вряд ли будет.
однако ФейсБук не сильно боится, и с недавних пор его использует очень активно.
Спасибо, очень полезно было.
НЛО прилетело и опубликовало эту надпись здесь
дайте ответ на мой вопрос:
почему процесс oauth твиттера\гугла отличаются от oauth яндекса?
почему процесс oauth твиттера\гугла отличаются от oauth яндекса?
Wow, первый «блог компании ХХХ» прочитаный с удовольствием. Good job!
Самый главный минус — это когда mail.ru закроют или продадут, придет новая метла и начнет мести по новому.
Один плюс — это, то что пользователю не нужно регистрироваться, он может быстро авторизоваться, под своим логином от mail.ru
Один плюс — это, то что пользователю не нужно регистрироваться, он может быстро авторизоваться, под своим логином от mail.ru
Хм… как я понял всё вышеизложенное, авторизоваться может не пользователь на вашем сайте, а ваш сайт в аккаунте пользователя, то есть пользователь сообщает mail.ru, что он этому сайту разрешает делать в mail.ru от своего имени (отправлять/получать почту, например). Для быстрой аутентификации пользователя на своём сайте нужно использовать OpenID или его аналоги, а авторизацию проводить своей логикой.
Для второго случая
Есть ли какие-нибудь препятствия для получения кода страницы авторизации через, например, курл, парсинг её, вывода пользователю, скажем, диалогового окна (или вообще хранить логин/пароль в настройках), отправки запроса через тот же курл и т. д.? Может ли это считаться «встроенным браузером» или такой вариант ничем не отличается от третьего и только лишние сложности для разработчика?
А вообще не понял, как собственно через API отправлять и получать письма и чем использование API лучше POP/SMTP? Ткните, пожалуйста, носом в конкретный док :)
Открытие встроенного браузера со страницей авторизации
Есть ли какие-нибудь препятствия для получения кода страницы авторизации через, например, курл, парсинг её, вывода пользователю, скажем, диалогового окна (или вообще хранить логин/пароль в настройках), отправки запроса через тот же курл и т. д.? Может ли это считаться «встроенным браузером» или такой вариант ничем не отличается от третьего и только лишние сложности для разработчика?
А вообще не понял, как собственно через API отправлять и получать письма и чем использование API лучше POP/SMTP? Ткните, пожалуйста, носом в конкретный док :)
«Встроенный браузер» в виде курла это хак системы ) Это авторизация по логину и паролю, только вместо одного запроса получается куча возни с курлом. Полноценный встроенный браузер обеспечивает несколько преимуществ:
* знакомый, понятный пользователю интерфейс
* если пользователь уже аутентифицирован на сервисе, то ему в приложении логин с паролем вводить не придется
* если пользователь аутентифицирован на сайте и уже авторизовывал приложение, то диалог запроса авторизации показываться не будет, будет сразу редирект с access token'ом
На счет API для почты. Действительно, для этого уже есть готовые стандартные протоколы, поэтому OAuth у нас реализован для «социальных» API — работы с друзьями, фотографиям, музыкой, личными сообщениями. Полный список доступных функций — api.mail.ru/docs/reference/rest/. В будущем, когда будет понятный общепринятый стандарт для интеграции OAuth с почтой, мы поддержим и его.
* знакомый, понятный пользователю интерфейс
* если пользователь уже аутентифицирован на сервисе, то ему в приложении логин с паролем вводить не придется
* если пользователь аутентифицирован на сайте и уже авторизовывал приложение, то диалог запроса авторизации показываться не будет, будет сразу редирект с access token'ом
На счет API для почты. Действительно, для этого уже есть готовые стандартные протоколы, поэтому OAuth у нас реализован для «социальных» API — работы с друзьями, фотографиям, музыкой, личными сообщениями. Полный список доступных функций — api.mail.ru/docs/reference/rest/. В будущем, когда будет понятный общепринятый стандарт для интеграции OAuth с почтой, мы поддержим и его.
Первый вариант это да, отчасти — для кого-то IE это браузер, а вот webkit в контроле может быть и не понятен чем-то :)
Встроенный браузер, афаик, выполняется в контексте приложения и то, что пользователь находится на сайте в основном браузере никак не поможет ему, если пытается зайти через встроенный
Курл, по идее, должен тоже авторизоваться раз и навсегда, все что знает браузер, знает и он :)
Спасибо за линк, будем искать полезное. Просто как-то думал, что раз mail.ru это прежде всего почта, то и API должно прежде всего доступ к функциям почты предоставить :)
Встроенный браузер, афаик, выполняется в контексте приложения и то, что пользователь находится на сайте в основном браузере никак не поможет ему, если пытается зайти через встроенный
Курл, по идее, должен тоже авторизоваться раз и навсегда, все что знает браузер, знает и он :)
Спасибо за линк, будем искать полезное. Просто как-то думал, что раз mail.ru это прежде всего почта, то и API должно прежде всего доступ к функциям почты предоставить :)
Как пользователь может быть уже авторизован на сервисе во встроенном браузере?
Да, я был не прав. Куки не шарятся между приложениями, поэтому пользователь не может быть сразу аутентифицирован, если только он не делал этого раньше в этом приложении.
Либо можно зарегистрировать специальный протокол на ваше приложение и открывать авторизацию в стандартном браузере с соответствующим redirect_uri. Тогда магия кук сработает.
Спасибо! Как раз искал информацию об этом
А где в mail.ru интерфейс управления токенами для пользователя?
Если он хочет отозвать токен для какого-то приложения?
Если он хочет отозвать токен для какого-то приложения?
И ещё у вас неправильный content-type при положительном ответе.
Должен быть application/json, а у вас text/javascript.
Должен быть application/json, а у вас text/javascript.
Хотя в примере в этой статье указн application/json, но в реальности, как я описал выше ;)
Вот здесь — my.mail.ru/cgi-bin/connect/view
Промахнулся с ответом. Это был ответ на вопрос «А где в mail.ru интерфейс управления токенами для пользователя?»
С content-type уточню в понедельник почему он у нас именно такой.
С content-type уточню в понедельник почему он у нас именно такой.
И раз уж пошёл разговор о content-type, REST API ваш отдает JSON ответы с типом text/plain.
Это тоже никужа не годится.
Это тоже никужа не годится.
text/javascript выбрали потому что в браузерах по-дефолту application/json скачивается как файл. Не удобно дебажить, разработчики жаловались. REST API поправим
Нифига себе не удобно :)
В стандарте сказано, что content type должен быть application/json.
Половина библиотек для OAuth обламываются.
В стандарте сказано, что content type должен быть application/json.
The parameters are included in the entity body of the HTTP response
using the «application/json» media type as defined by [RFC4627]. The
parameters are serialized into a JSON structure by adding each
parameter at the highest structure level. Parameter names and string
values are included as JSON strings. Numerical values are included
as JSON numbers
Половина библиотек для OAuth обламываются.
Люди добрые, если есть силы, посоветуйте, в чем проблема у меня с аутентификацией через твиттер (ASP .NET MVC):
Сначала пользователя кидаю на страницу входа через твиттер (использую consumerKey и сonsumerSecret, что получил при регистрации приложения на dev.twitter):
* var tokenResponse = OAuthUtility.GetRequestToken(ConfigurationManager.ConnectionStrings[«consumerKey»].ConnectionString, ConfigurationManager.ConnectionStrings[«consumerSecret»].ConnectionString, ConfigurationManager.ConnectionStrings[«callBackUrl»].ConnectionString);
* var token = tokenResponse.Token;
* var url = OAuthUtility.BuildAuthorizationUri(token).AbsoluteUri;
* return Redirect(url);
После чего, получив oauth_token, oauth_verifier и попробуем получить accessToken:
* string Oauth_Token = Request.QueryString[«oauth_token»].ToString();
* string Oauth_Verifier = Request.QueryString[«oauth_verifier»].ToString();
* OAuthTokenResponse accessToken = OAuthUtility.GetAccessToken(ConfigurationManager.ConnectionStrings[«consumerKey»].ConnectionString, ConfigurationManager.ConnectionStrings[«consumerSecret»].ConnectionString, Oauth_Token, Oauth_Verifier);
и вот здесь засада. Раньше все работало (месяц назад). Сейчас это проходит раз из пяти попыток. Выдается сообщение что твиттер шлет 401 ошибку, и выскакивает exception.
( добавлю, что значения Oauth_Token и Oauth_Verifier приходят)
Если есть идеи, напишите пожалуйста, буду очень благодарен
Сначала пользователя кидаю на страницу входа через твиттер (использую consumerKey и сonsumerSecret, что получил при регистрации приложения на dev.twitter):
* var tokenResponse = OAuthUtility.GetRequestToken(ConfigurationManager.ConnectionStrings[«consumerKey»].ConnectionString, ConfigurationManager.ConnectionStrings[«consumerSecret»].ConnectionString, ConfigurationManager.ConnectionStrings[«callBackUrl»].ConnectionString);
* var token = tokenResponse.Token;
* var url = OAuthUtility.BuildAuthorizationUri(token).AbsoluteUri;
* return Redirect(url);
После чего, получив oauth_token, oauth_verifier и попробуем получить accessToken:
* string Oauth_Token = Request.QueryString[«oauth_token»].ToString();
* string Oauth_Verifier = Request.QueryString[«oauth_verifier»].ToString();
* OAuthTokenResponse accessToken = OAuthUtility.GetAccessToken(ConfigurationManager.ConnectionStrings[«consumerKey»].ConnectionString, ConfigurationManager.ConnectionStrings[«consumerSecret»].ConnectionString, Oauth_Token, Oauth_Verifier);
и вот здесь засада. Раньше все работало (месяц назад). Сейчас это проходит раз из пяти попыток. Выдается сообщение что твиттер шлет 401 ошибку, и выскакивает exception.
( добавлю, что значения Oauth_Token и Oauth_Verifier приходят)
Если есть идеи, напишите пожалуйста, буду очень благодарен
А что если при авторизации Standalone приложения я таки хочу передать redirect_uri? Сейчас это невозможно — редиректит всегда на стандартную заглушку — что неудобно в плане перехвата редиректа из системного браузера.
Вот если бы можно было задать redirect_uri типа myApplicationAuth:://success было бы кул.
В чем причина такого ограничения?
Вот если бы можно было задать redirect_uri типа myApplicationAuth:://success было бы кул.
В чем причина такого ограничения?
Не получается для сайта обменять code на access_token
Успешно получив code делаю POST-запрос, с заголовком Content-Type: application/x-www-form-urlencoded на connect.mail.ru/oauth/token
В ответ получаю {«error»:«unsupported_grant_type»}
Параметры запроса у меня такие (изменены):
[grant_type] => authorization_code
[code] => dbef95fb3cxxxxxxdfc06661ee68ed90
[client_id] => 678xxx
[client_secret] => 686907143a40xxxxxxda15931dxxxxxx
[redirect_uri] => site.ru
т.е., все необходимые параметры передаются, почему такая ошибка если grant_type правильный?
Успешно получив code делаю POST-запрос, с заголовком Content-Type: application/x-www-form-urlencoded на connect.mail.ru/oauth/token
В ответ получаю {«error»:«unsupported_grant_type»}
Параметры запроса у меня такие (изменены):
[grant_type] => authorization_code
[code] => dbef95fb3cxxxxxxdfc06661ee68ed90
[client_id] => 678xxx
[client_secret] => 686907143a40xxxxxxda15931dxxxxxx
[redirect_uri] => site.ru
т.е., все необходимые параметры передаются, почему такая ошибка если grant_type правильный?
А как тогда использовать OAuth для (подчёркиваю) аутентификации? Приложению необходимо связать какие-то данные с пользователем. По какому идентификатору это будет делаться?
OAuth не предназначен для аутентификации. Он нужен для того, чтобы ваше приложение или сайт могли от лица пользователя делать какие-то действия в гугле, мейле или еще где-нибудь, при этом, что это за пользователь вы можете и не знать.
Многие системы (мэйл, фб, вк и т. п.) позволяют после авторизации запросить данные о пользователе. То есть, если через OAuth запросить авторизацию, а потом, используя API сервиса и полученную авторизацию, получить данные о пользователе, то их можно использовать для аутентификации. Но это уже надо курить API каждого конкретного сервиса и напрямую к OAuth это не относится.
Многие системы (мэйл, фб, вк и т. п.) позволяют после авторизации запросить данные о пользователе. То есть, если через OAuth запросить авторизацию, а потом, используя API сервиса и полученную авторизацию, получить данные о пользователе, то их можно использовать для аутентификации. Но это уже надо курить API каждого конкретного сервиса и напрямую к OAuth это не относится.
Пробую в бизнес центре подключиться к wi-fi. Мне предлагают авторизоваться через OAuth (vk, fb, twitter). Какой смысл в авторизации, если они не получают инфорацию о том, кто подключился? Или все-таки получают? Какую еще информацию они смогут выудить из моего аккаунта при авторизации? Почему OAuth, а не OpenID? Там бы я сказал, что я — zelserg без риска передачи пароля или какой другой информации о себе (телефоны, e-mail и пр).
Не знаю, что там у Twitter/Facebook, но у VK нет ни поддержки OpenID, ни OpenID Connect (с выдачей ID Token). Поэтому единственный вариант — получить полноценный access token и использовать методы vk api для получения информации для идентификации пользователя.
Ту, которую разработчики запросят в scope при авторизации и вы подтвердите. В случае вк, как я уже сказал, достаточно пустого scope: для доступа к информации о профиле дополнительных прав не нужно.
Но никто не мешает разработчикам сервиса запросить чуть больше прав, чем необходимо. Например, чтобы постить пользователю на страницу. Это будет явно показано в момент авторизации приложения (см. scope wall), но большинство пользователей не смотрят на запрашиваемые права. А если и смотрят, то вариантов нет: или разреши спамить, или никакого тебе wifi.
Какую еще информацию они смогут выудить из моего аккаунта при авторизации?
Ту, которую разработчики запросят в scope при авторизации и вы подтвердите. В случае вк, как я уже сказал, достаточно пустого scope: для доступа к информации о профиле дополнительных прав не нужно.
Но никто не мешает разработчикам сервиса запросить чуть больше прав, чем необходимо. Например, чтобы постить пользователю на страницу. Это будет явно показано в момент авторизации приложения (см. scope wall), но большинство пользователей не смотрят на запрашиваемые права. А если и смотрят, то вариантов нет: или разреши спамить, или никакого тебе wifi.
Спасибо, информация оказалась полезной!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
OAuth 2.0 простым и понятным языком