LINUX.ORG.RU

Как правильно готовить OAuth

 , , , ,


0

1

У меня сейчас небольшая каша в голове. Пожалуйста, объясните мне, как сделать кое-что наиболее правильным образом.
У меня есть два приложения: веб-приложение на GAE и десктопное приложение. Суть в том, что десктопное приложение должно отправлять информацию в веб-приложение.
Дополнительная регистрация на каждом сайте всех достала, потому заюзаем OpenID или OAuth. Вопрос в том, где должна происходить авторизация. Нужно делать авторизацию только в веб-приложении или в десктопном тоже?

★★★★★

Ответ на: комментарий от orm-i-auga

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

CYB3R ★★★★★
() автор топика
Ответ на: комментарий от orm-i-auga

Есть сайт с базой данных (веб-приложение), есть десктопное приложение, которое в эту базу пишет.
Сейчас я думаю, что здесь нельзя будет обойтись без двойного OAuth (и в веб-приложении, и в клиентском приложении). Если делать только в веб-приложении, то обязательно придётся копировать ключ из браузера и записывать его в конфиг, что пользователю неинтересно.

CYB3R ★★★★★
() автор топика

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

Дальше всё как обычно, тем более, что юзеры на GAE уже умеют в openID.

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

Можно сделать клиента потолще и включить в него браузер, тогда авторизация будет только на сервере, но вряд ли у этого способа есть какие-нибудь преимущества.

orm-i-auga ★★★★★
()

Единственно верный метод приготовления OAuth заключает в том, что надо завернуть его в тяпочку и выбросить в мусоропровод.

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

Получается, у меня будет два браузера. Один — браузер клиента, которым он логинится в веб-приложение, второй на libcurl, который только отправляет данные из консоли. Даже не знаю, как там правильно будет логиниться и хранить куки.

CYB3R ★★★★★
() автор топика

я эту ситуацию так решаю:

вебсайт авторизует юзеров через oauth, и в базе хранит закешированные userinfo, + генерирует GUID через mysql uuid() для каждого юзера.

десктоп приложение авторизуется на сайте через login+guid, которые юзер вводит в конфиг файл, а получить guid он может из профиля на вебсайте. посылаем login+guid, получаем cookie, и можем с сайтом общаться через REST (или любой другой API).

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

Да, уже смотрю. Писать, наверное, буду на vala. Там с этим должно быть просто.

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

Кажется, я придумал ещё более лёгкий способ:

  • OAuth в веб-приложение (узнаём email пользователя).
  • Кликаем в веб-приложении «Подключить клиент в ближайшие 5 минут».
  • В десктопном клиенте вводим email, на основе хэша которого будет сформирован URL, куда клиент стучится.
  • Если 5 минут не прошли, то клиент спокойно обменивается своими данными. Если прошли, то по этому URL отдаётся 404.

Главное, чтобы за клиентом никто не следил и на сервере использовался тот же алгоритм хэширования, что и на клиенте.

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

этот способ плох тем, что придется постоянно через браузер заходить. но может тебе это и подходит.

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

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

Я просто хотел изначально вообще этих телодвижений обойтись, но не выйдет.

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