We are writing to inform you that OAuth out-of-band (OOB) flow will be deprecated on October 3, 2022, to protect users from phishing and app impersonation attacks.
У меня всё работало, меня всё устраивало. Я не знаю что такое OAuth и не хочу в этом разбираться.
#1 хочет залогиниться на #2 через #0, подтвердив, что он и есть тот пользователь. Не могу понять flow, которым это кошерно организовать через OAuth.
Мое предположение костыльное. #1 получает токен для доступа у #0 путем стандартного Authorization Code Grant через сайт. Затем, когда надо, #1 сам регистрируется на #2 с client_credentials. И получает как бы ключ сессии. Потом просит у #0 некий код для #2 подтвердив себя своим же токеном, который у него уже есть. #1 отдаёт полученный код в #2, #2 получает у #0 по коду токен и записывает, что считать эту сессию с #1 аутентифицированной как вот тот пользователь, что он захватил у #0.
Но я вот сомневаюсь по поводу пункта "просит у #0 некий код для #2 подтвердив себя своим же токеном". Может есть стандартная последовательсность действий? scontent.xx.fbcdn.net
Есть три сервиса, работающих по OAuth 2.0. Service#0 — там основные данные пользователя. Сайт — это "морда" к Service#1, куда пользователь штатным образом с редиректами логинится через Service#0. Задача — подключить Service#2 к Service#1 (не к сайту, а именно к серверу), так чтобы Service#2 поимел ключ доступа к данным Service#0 для того же ресурса, что и Service#1. Другими словами — Мое предположение костыльное. #1 получает токен для доступа у #0 путем стандартного Authorization Code Grant через сайт. Затем, когда надо, #1 сам регистрируется на #2 с client_credentials. И получает как бы ключ сессии. Потом просит у #0 некий код для #2 подтвердив себя своим же токеном, который у него уже есть. #1 отдаёт полученный код в #2, #2 получает у #0 по коду токен и записывает, что считать эту сессию с #1 аутентифицированной как вот тот пользователь, что он захватил у #0.
Но я вот сомневаюсь по поводу пункта "просит у #0 некий код для #2 подтвердив себя своим же токеном". Может есть стандартная последовательсность действий? scontent.xx.fbcdn.net
Ынтерпрайз, блин.
PS в сети искал. Пока ответа не нашёл. Подозреваю что привязка должна быть.
мне например openid больше нравится. потому что можно легко поменять его, по сути не такая жесткая привязка к сети, которая его выдает.
А я сижу удивляюсь почему у меня их авторизация не проходит.
goo.gl В то время как на руби/рельсах я без всякого опыта разработки на них поднял за пару часов нужную мне систему, реализации провайдера oauth больше, и при этом с отличной документацией и примерами. А теперь надо сделать oauth2 на tornado, и на этом застопорился, провел отличную работу для архитектуры проекта, набросал будущий API, так что бы проект выполнялся менее опытным без проблем, а вот на куске с oauth фиг знаю что сделать, хоть сам садись и пиши костыль очередной. Для django хоть год назад появился oauth2app goo.gl и то хорошо.
Ох как я это понимаю – «The sorry state of Python OAuth providers» Неожиданная ошибка $1 при обновлении твита. Попробовать снова.Они хотят один бакс за обновление твита!!! -_-
github.com ! Конечно, немного быдлокод, но надо будет заюзать, своё писать всё-равно лень, кекеке.
А завтра нужно будет подключать гугл... Привет Кстати, OpenID оказался нафиг никому не нужен, все используют Facebook Connect. :)
#634775 можно написать своего жуйкобота с шахматами и поэтессами? Можно и подписку на теги устроить и свой синтаксис комманд прикрутить, при этом работать вы будете с одним ботом. Чисто для себя это можно было и раньше сделать, но теперь такого бота можно сделать доступным массам. Для желающих заводим уникальный jid на домене сервиса, предлагаем юзера добавить его в свой аккаунт и спрашиваем у юзера код авторизации. Всё! Дальнейшую работу с джуйком юзер может вести через тот самый jid: постить сообщения, подписываться на теги, получать ответы в любом виде и тд. Для полного счастья хотелось бы чтобы это было реализовано через oAuth, дабы юзеру оставалось только нажать кноку разрешить доступ сервису, но и это уже хорошо.
А вы знаете, что с введением новой фичи OAuth access to IMAP/SMTP in Gmail via feedproxy.google.com from GoogleReader