• OAuth 2.0 простым и понятным языком
    0
    OAuth не предназначен для аутентификации. Он нужен для того, чтобы ваше приложение или сайт могли от лица пользователя делать какие-то действия в гугле, мейле или еще где-нибудь, при этом, что это за пользователь вы можете и не знать.

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

  • OAuth 2.0 простым и понятным языком
    0
    text/javascript выбрали потому что в браузерах по-дефолту application/json скачивается как файл. Не удобно дебажить, разработчики жаловались. REST API поправим
  • OAuth 2.0 простым и понятным языком
    0
    Промахнулся с ответом. Это был ответ на вопрос «А где в mail.ru интерфейс управления токенами для пользователя?»

    С content-type уточню в понедельник почему он у нас именно такой.
  • OAuth 2.0 простым и понятным языком
    +1
    Вот здесь — my.mail.ru/cgi-bin/connect/view
  • OAuth 2.0 простым и понятным языком
    +1
    Либо можно зарегистрировать специальный протокол на ваше приложение и открывать авторизацию в стандартном браузере с соответствующим redirect_uri. Тогда магия кук сработает.
  • OAuth 2.0 простым и понятным языком
    +1
    Да, я был не прав. Куки не шарятся между приложениями, поэтому пользователь не может быть сразу аутентифицирован, если только он не делал этого раньше в этом приложении.
  • OAuth 2.0 простым и понятным языком
    +1
    «Встроенный браузер» в виде курла это хак системы ) Это авторизация по логину и паролю, только вместо одного запроса получается куча возни с курлом. Полноценный встроенный браузер обеспечивает несколько преимуществ:
    * знакомый, понятный пользователю интерфейс
    * если пользователь уже аутентифицирован на сервисе, то ему в приложении логин с паролем вводить не придется
    * если пользователь аутентифицирован на сайте и уже авторизовывал приложение, то диалог запроса авторизации показываться не будет, будет сразу редирект с access token'ом

    На счет API для почты. Действительно, для этого уже есть готовые стандартные протоколы, поэтому OAuth у нас реализован для «социальных» API — работы с друзьями, фотографиям, музыкой, личными сообщениями. Полный список доступных функций — api.mail.ru/docs/reference/rest/. В будущем, когда будет понятный общепринятый стандарт для интеграции OAuth с почтой, мы поддержим и его.
  • OAuth 2.0 простым и понятным языком
    0
    Мы не знали о такой проблеме. Где можно посмотреть? Поправим.
  • OAuth 2.0 простым и понятным языком
    0
    Разница в версиях стандарта. Твиттер и гугл используют oauth 1.0. Яндекс, Mail.Ru, Facebook и др. используют вторую версию. Вторая версия гораздо проще в реализации и понимании. Думаю, в будущем на нее перейдут все.
  • OAuth 2.0 простым и понятным языком
    +2
    У нас для сайтов есть специальная js-обертка, которая избавляет от проблем с изменением стандарта — api.mail.ru/docs/guides/jsapi/.

    Но, в принципе, там все настолько просто, что сильно меняться оно уже вряд ли будет.
  • Авторизация пользователей через Mail.Ru API: большой эффект маленькой кнопки
    0
    oAuth 2.0 уже работает — api.mail.ru/docs/guides/oauth/
  • Авторизация пользователей через Mail.Ru API: большой эффект маленькой кнопки
    0
    Поддержка oAuth 2.0 в разработке, будет в течение ближайших месяцев.
  • Авторизация пользователей через Mail.Ru API: большой эффект маленькой кнопки
    0
    Это историческое название. Поменять пока не можем из-за обратной совместимости :(
  • Авторизация пользователей через Mail.Ru API: большой эффект маленькой кнопки
    +4
    На самом деле, там практически user-agent flow из oAuth 2.0. Разница в названиях параметров и некоторых деталях. Когда начинали делать, спецификации еще не было.

    В скором будущем приведем к стандарту, благо, js либа это абстрагирует.
  • Новые возможности Mail.Ru API
    +1
    пока можно оплачивать только одной смс. на край это можно обойти: положить смсками денег на какие-нибудь деньги@mail.ru, а потом заплатить с них. не удобно, конечно. подумаем над реализацией такой фичи.
  • Новые возможности Mail.Ru API
    0
    открывать в новом окне нельзя, но максимальная ширина приложения 760 пикселей
  • Новые возможности Mail.Ru API
    +1
    менять высоту уже можно
  • Новые возможности Mail.Ru API
    +1
    А еще мы приложения модерируем за один рабочий день :)

    На счет того, что с локальной машине не удобно разрабатывать, знаем, планируем улучшить этот аспект.

    Возможность усправления скроллом сделаем.
  • Mail.Ru открыл API для внешних сайтов
    +1
    Пока это будет нетривиальной задачей :) Можно сделать вот что: залить receiver.html на доступную из интернета машину и зарегистрировать сайт, потом прописать домен этого сайта у себя в hosts, чтобы браузер обращался локально (receiver.html залить на локальную тоже). Так как все кроссдоменное взаимодействие происходит внутри браузера, то девелоперская может не иметь внешнего ip.

    Будем упрощать процесс для таких случаев.
  • Mail.Ru открыл API для внешних сайтов
    +2
    У мэйл.ру есть давно работающая реализация openid — openid.mail.ru/

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