Comments 89
на самом деле вменяемый драфт, по которому можно уже было реализовать этот протокол, появился в середине прошлого года. А финальная версия пару месяцев назад.
Но главное то, что некоторые крупные сайты ввели это в начале этого года, а вконтакте очнулся только спустя 2-3 месяца, что не очень.
Финальная версия так и не появилась.
Постоянно приходится перечитывать протокол и находить в нем изменения.
Последний драфт от 6 апреля, версия 15 (draft-ietf-oauth-v2.0-15)
Лучше поздно, чем последними. OAUTH это хорошо, теперь остались только Одноклассники (Мой Мир уже поддержал).
Если бы своих костылей в виде OpenAPI не писали, были бы еще большими молодцами)
Наконец то. Только чувствую, какой то подвох таки будет… они не могут сделать все хорошо
дай бог если вы правы, если же нет, то это десятки безсонных ночей работы с их велосипедами, а потом полное разочаровние в том, что они опять все поменяют
кстати, вчера только задумался над тем — почему ВК не сделали еще OAuth… бывает же:)
спасибо К.О., я имел ввиду способ авторизации, а не версию протокола :)
И что теперь можно через стандартные либы OAuth использовать еще и vk? Интересует пример на питоне.
У меня сегодня получилось работать с oauth v.2 и с facebook и с vkontakte
Я пишу django-приложение для авторизации через социальные сети: bitbucket.org/lorien/django-xauth/src
Вот работа с oauth2: bitbucket.org/lorien/django-xauth/src/fbb5cb33026a/xauth/service/oauth2/views.py
Для работы с oauth v.2 я использовал следующую библиотеку: github.com/ryanhorn/tyoiOAuth2
UFO landed and left these words here
У этих протоколов разное назначение: OAuth преимущественно для авторизации клиента, передающего данные. OpenID — для унификации авторизации
Сейчас большинство сайтов, поддерживающих OpenID, сделали поддержку входа через соц. сети, так что OpenID уже не станет таким популярным, как мог быть.
Это правда. OpenID в реализации на порядок сложнее чем простенькая авторизация, а смысл тот же
Это вы зачем людей в заблуждение вводите?

Сходите, изучите значение слов «сложнее» и «порядок», пожалуйста.
О, тролль.

Ну расскажите мне, чем это OpenID сложнее, чем OAuth. И заодно софистику «OAuth преимущественно для авторизации клиента, передающего данные. OpenID — для унификации авторизации» проясните.

А то пацаны в лице автора протокола пока-то и не в курсе.
OpenID в реализации на порядок сложнее чем простенькая авторизация



UFO landed and left these words here
UFO landed and left these words here
Это в сочетании с OAuth — прямая дорога к монетизации, кстати. OAuth ведь обычно нужен приложениям.
Сделали бы еще, чтобы email отдавался, как у гугли и того же фейсбука.
А смысл? Вот представте ситуацию — у нас есть некий ресурс, предположим docme.ru, и есть на нем авторизация с помощью VK, Yandex, Mail.ru и пр. Допустим, упал вконтакт, такое уже бывало, и наши пользователи не могут получить доступ к своему аккаунту. Но, имея мыла на руках, можно сделать восстановление доступа, временное или постоянное. А так мыло приходится спрашивать дополнительно при регистрации, и не факт, что оно будет «правильное».

Это кстати из реальной жизни, мы на ДокМи с этим столкнулись, когда Mail.ru упал, и благо, что пользователей от него не так много в настоящий момент. Однако письма в тех.поддержку посыпались моментально. Так что я считаю — мыло крайне необходимо, если даешь oauth|openid|etc. Вопрос даст ли его пользователь — дело второе. Все-таки сеть — штука нестабильная
UFO landed and left these words here
Ну гугль и фейсбук не боятся, в сумме думаю акков у них поболее будет, и ничего, не параноят.
А для параноиков — все просто — галка с выбранным пунктом «дать доступ к мылу» в окошке подтверждения, параноики эту галку снимут.
Для десктопных прог нет ограничений? А то сейчас у нас весьма ядреная авторизация используется и она не срабатывает на мобилках((
OAuth построена на http. Если у десктопной проги нет ограничений на использование http-протокола, то и ограничений для авторизации быть не должно.

Быть может, вы об авторизации через ява-апплеты какие-нибудь говорите?
Нет, для десктоп-приложений была трёхступенчатая авторизация через перезагрузку страниц, с яваскриптом и куками. Подразумевалось, что мобильное приложение должно просто открыть эту страницу во встроенном браузере и потом им полагалось как-то управлять ещё. Что вообще малореально. В мобилах и правда были большие проблемы с этим. Приходилось выкручиваться или через эмуляцию этих костылей через http-запросы или выносить авторизацию наружу приложения куда-нибудь.
UFO landed and left these words here
Нет, имеется в виду, что можно использовать новый формат запросов используя access_token
UFO landed and left these words here
IFrame приложения могут использовать OpenAPI. Схема авторизации аналогична сайтам.
Было вообще круто, если б они хорошенько протестировали основной функционал перед запуском. Залогинеться у меня получилось, а вот насрать на свою же стенку или вытащить полную инфу о себе уже не могу, errorы возвращает. Конечно допускаю, что я что-то не верно сделал, но access_token получил валидный, могу достать список своих друзей.
Писать на стену можно по прежнему только desktop приложениям, либо приложениям отправившим запрос на apps@vkontakte.ru. Каким образом Вы пытаетесь получить полную информацию?
Ну собственно через «getProfiles».
У них на странице Выполнение запросов к API написано, что «METHOD_NAME – название метода из списка функций API». А в этом списке есть как «getProfiles», так и «wall.post».

Выходит сделали коннект, а сделать «больше» ничего пока нельзя. Так хотя бы написали б об этом, а то непонятно.
getProfiles работает, только что проверил, можно пожалуйста код запроса (access_token можно затереть).
Сори, с getProfiles мой бок. Я не передавал в запрос «fields». Как-то подумал, что если его не передать, товернется вся доступная инфа по пользователю. По мойму это логично :)

Но с «wall.post» проблема пока актуальна. :)
Да, значения uid, first_name и last_name возвращаются всегда, вне зависимости от выбранных полей и их количества. Для вытягивания остальных значений необходим access_token и список полей, которые хочешь вытянуть. В другой ветке я описал, что это был мой бок, нужно всегда передавать список полей, которые тебя интересуют.
А вы не знаете, можно получить ленту новостей для стороннего сайта?
Вообще это метод newsfeed.get (http://vkontakte.ru/developers.php?o=-1&p=newsfeed.get). Но что вы с этими данными хотите сделать я не совсем понял))

Я например для Gwibber (микроблог-клиент в Linux) плагин через него написал. Если нужен пример кода — можете поглядеть code.launchpad.net/~seriy-pr/gwibber/vkontakte-ru-plugin (Python)
Спасибо за ответ. Я хочу выводить ленту у себя на сайте. Когда я смотрел, и если я правильно понял (это было прим. месяц назад), то этот метод может использовать или программа или моб. клиент, но не сторонний сайт. Вот тут и хотелось бы уточнить, ошибаюсь ли я?
Может быть у вас по опыту работы с api vk есть какой то свой способ вытащить новости друзей, если официальным методом этого сделать нельзя?
Да, есть загвоздка, что токен API привязан к IP адресу с которого происходит авторизация (с которого открывается браузер и нажимается кнопка «разрешить» в веб-интерфейсе).
Так что с сервера, как я понял, без хаков этого не сделать…
Так что либо пишем проксик и запускаем на сервере чтоб IP совпадали либо парсим форму авторизации (но я этого не пробовал ибо у меня десктоп-клиент)
Но я могу и ошибаться на самом деле…
Хорошо спасибо большое.

Вот еще бы этот метод сделали для сторонних сайтов, было бы вообще хорошо)
О! Кстати! Только что нашел параметр авторизации «offline» вот тут последний. В фейсбуке есть одноименный параметр который позволял как-раз обращаться к API с сервера. Попробуйте его. Я сейчас тоже попробую))
Сергей, а у Вас сейчас работает этот параметр? У меня почему-то именно с ним при авторизации выдается ошибка
{
error: "invalid_grant"
error_description: "Code is invalid or expired."
}


А с остальными нормально
У меня вот такие параметры:
      "client_id": VK_APP_ID,
      "redirect_uri": "http://vkontakte.ru/api/login_success.html", #FIXME: http://api.vkontakte.ru/blank.html don't fire "title-changed"
      "response_type": "token",
      "display": "popup",
      "scope": ",".join(("video", "offline", "wall"))
Все работает ок, хотя вчера почему-то глючило.
Слава богам, наконец-то смогу использовать без проблем в мобильных приложениях.
Извините, я не в курсе. Почему это противоречит идеям монетизации?
А зачем давать разлогинить пользователя без нужды? Чтобы он более ничего купить не мог?
Например если данным приложением будет пользоваться большое количество человек.
Я как бы отвечаю, почему метода нет в API. Все претензии — в администрацию вконтакта.
Я прошёл через полгода ожидания в страхе того, что html/js код страниц авторизации может измениться в любой момент. Господа веб-разработчики реально верят в то, что неотъемлемой частью любого desktop/mobile приложения является веб-браузер? >_<
При работе в AIR к сожалению, выхода другого не вижу (. Приходится плясать с бубном и боятся изменений формы авторизации.
У них бы еще саппорт нормальный появился, в который раз отклоняют приложение с формулировкой «Приложение не соответствует уровню в контакте» без объяснения причин, и на комментарии не отвечают… Плюс к этому еще и голоса не вернули, которые:
Размещение приложений и их одобрение бесплатны. Однако, в связи с большим количеством заявок на проверку приложений, взятых со сторонних сайтов, для отправки приложения на проверку необходимо внести залог в 10 голосов.
Наконец-то можно будет сделать нормальную внебраузерную авторизацию, ура!
Браузер все равно нужен что бы вводить логин/пароль и давать права для приложения. Так что нет, не получится…
Вот. Только что перенес код плагина VKontakte для Gwibber на новую ваторизацию. Получилось довольно мало изменений. Кому интересно — вот DIFF.
По впечатлениям — вроде проще стало и аккуратнее и логичнее чтоли. Хотя на пару недочетов наткнулся + документация запутанная. Так, например, страница для редиректа по-умолчанию для десктоп-приложений api.vkontakte.ru/blank.html не имеет title и в python-webkit не срабатывает событие «title-changed». Приходится эту vkontakte.ru/api/login_success.html использовать пока.
а кроме как title-changed никак нельзя прослушать, что страница изменена?
Ох… Может и можно, но это самый простой вариант и в Gwibber везде именно он используется. Я, честно говоря, не помню)))

Но, как уже сказал, решилось использованием страницы-заглушки от старого API у которой title есть vkontakte.ru/api/login_success.html
А безбраузерная авторизация для десктоп\мобильных приложений все так же почти (кроме как сильно через жо) невозможна?

Под WP7 у меня авторизироваться через браузер так и не получилось (категорически отказывались подгружаться поля для логина и пароля).
Насколько мне лично известно, OAuth не предусматривает безбраузерной авторизации впринципе. Это все для того чтобы злой создатель программы не смог украсть ваш логин и пароль (хотя для десктоп-программ это по-прежнему не проблема)
Добавил поддержку OAuth2 для ВКонтакте в django-social-auth: Довольно просто получилось. Единственный небольшой минус по сравнению с OpenAPI — 1 дополнительный вопрос к пользователю. Но как его избежать представляется с трудом.
Only those users with full accounts are able to leave comments. Log in, please.