LINUX.ORG.RU

oAuth2, доступ к типовым данным пользователя

 ,


1

3

Правильно я понимаю что oAuth2 стандартизирует только получение токена, а дальнейшая работа с сервисом (с использованием этого токена) не стандартизирована никак? Или просто не все провайдеры реализуют эту часть? Или я слепой?
Т.е. выходит для реализации стандартного «войти через социалочки» нужно под каждую социалочку писать отдельный код для получения как минимум имени пользователя и аватара? Нельзя реализовать oAuth-клиент в общем виде и добавлять поддержку новых провайдеров просто указывая для них URLы и clientSecret-ы?
Но это же… ненужно.

★★★★★

Ты прав. Можешь начать с библиотек, где это уже реализовано, для твоей платформы (ЦМС, движка, языка). Например, publicauth, devise, pytohn-social-auth etc etc etc.

anonymous
()
Ответ на: комментарий от anonymous

Не, я лучше начну с забивания на oauth. Ибо ненужно.
И вот в пользу этого закопали openID. Не лучше-ли было прикрутить к нему чёрно-белые списки провайдеров?

MrClon ★★★★★
() автор топика
Ответ на: комментарий от anonymous

А нет что-ли? На сколько я понимаю оно там не в самом протоколе, а поверх него, каким-то расширением, но оно более-менее стандартизированно.
В oAuth никакой стандартизацией этих васюков кажется и не пахнет, там весь протокол заточен под идею что есть десяток провайдеров которых хватит всем, и клиент может написать отдельный код под каждого нужного ему.

MrClon ★★★★★
() автор топика
Ответ на: комментарий от MrClon

В ОАуз оно тоже поверх протокола, малыш, просто каждый провайдер по-своему именует поля: у кого-то логин это username, у кого-то login, у кого-то display_name а у кого-то displayName и жить красиво никому не запретишь, потому-что у всех это разные доменные объекты. У кого-то есть имя на сайте, у кого-то имя вообще не вводится и так далее. О какой стандартизации ты тут распинаешься? О собственной реализации OAuth на ассемблере? Библиотеку должен выпускать сам провайдер, а что он в ней релизует его заботы и право, ты берешь готовое и интегрируешь со своим поделием, учитывая все нюансы поставщика, такова жизнь. Хватит тут тереть ересь, пиши-ка уже код, а?

anonymous
()
Ответ на: комментарий от anonymous

Ересь это писать отдельную реализацию под каждого провайдера. Минимальный и достаточный в 95% случаев набор данных прекрасно стандартизируется: имя (ник, имяфамилия или логин, на усмотрение провайдера), аватар (none если отсутствует), пол (none если не указан или в принципе не используется провайдером), дата рождения, email. Это набор который может предоставить почти любой провайдер и которого достаточно для большинства случаев.
Если-бы разработчики oAuth осилили это стандартизировать до добавлять новых провайдеров можно было-бы просто заполнив пару полей (APIшные URL и ключи). А то что мы имеем сейчас это недостандарт. Ведь никому не приходит в голову впиливать в браузеры отдельную реализацию, например, получения заголовка страницы для каждого сайта

MrClon ★★★★★
() автор топика
Ответ на: комментарий от MrClon

это реализуемо простым набором фильтров, вроде

data = {
"facebook": lambda data: {"username": "{}@facebook.com".format(data["id"]), "display_name": "{} {}".format(data["first_name"], data["last_name"]),
"twitter": lambda data: {"username": data["screen_name"] ...

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

anonymous
()
Ответ на: комментарий от anonymous

У того-же втентакля например вообще свой домотканный незалежный API для этого, с oAuth связанный только токеном. Там элементарным мапингом не обойдёшься.

Понятно что любую задачу можно решить просто написав ещё немного кода, вот только задач этих много и кода в результате очень много. В частности благодаря этому современный веб превратился в то адское тормознутое месиво в которое он превратился. Так-что я всеми силами стараюсь уменьшить количество необходимого кода. Унификация в этом деле очень помогает.
Руководствуясь принципом «просто пиши код, блеядь» я уже написал кучу этого самого кода которую до сих пор с переменным успехом приходится разгребать.

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

MrClon ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.