OAuth на iPhone: использование Safari или UIWebView? - PullRequest
4 голосов
/ 09 марта 2010

Когда я внедряю OAuth в iPhone, у меня возникает дилемма, чтобы выбрать Safari или UIWebView, чтобы открыть страницы Twitter для аутентификации пользователя? Я пишу некоторые преимущества и недостатки обоих случаев: Использование UIWebWeb. Недостатком является то, что пользователи должны вводить свои учетные данные в нашем приложении. Это может быть рискованный фишинг. Преимущество в том, что этот подход не выйдет из нашего приложения.

Использование Safari для аутентификации пользователя (этот подход автоматически вызывает обратные вызовы для нашего приложения). Преимущество: менее рискованно. Недостаток: придется выйти из нашего приложения

Хорошая справочная ссылка по этому поводу: http://fireeagle.yahoo.net/developer/documentation/oauth_best_practice

Какой подход вы предпочитаете? Любой ответ приветствуется. Спасибо.

Ответы [ 5 ]

3 голосов
/ 09 марта 2010

Парень, который пару лет назад делал приложение для iPhone от Pownce, вроде как публично обсуждал это с собой.

Его блог, похоже, больше не работает, но в основном он реализовал его "правильным" способом, что касается OAuth. Вместо ввода учетных данных внутри приложения, Safari был запущен, и они были введены там, а затем в качестве обратного вызова для перезапуска приложения Pownce использовался пользовательский URL-адрес iPhone. Довольно аккуратно, а?

Через некоторое время разработчик добавил, что многие люди скачивают приложение, но на самом деле не используют его. Его заключение? В этом была виновата его блестящая схема OAuth. Пользователи были смущены запуском Safari и удалением из приложения.

Если честно? Я думаю, что виноват тот факт, что приложение было для Pownce, службы, которой никто не пользовался.

У меня сейчас есть приложение в магазине приложений, использующее API Foursquare, которое поддерживает Basic HTTP-аутентификацию и OAuth. Я решил «поступать правильно» и использовать OAuth. Пользователь вводит свои учетные данные прямо внутри моего приложения. Сохраняю ли я где-нибудь их имя пользователя и пароль в виде обычного текста? Нету. Но могу ли я быть? Конечно.

Может показаться, что я спорю здесь с обеих сторон, но в действительности это сводится к тому, что очень маловероятно, что ваши пользователи будут знать или даже заботиться о том, что такое OAuth. Вероятно, столь же маловероятно, что они даже дважды подумают о вводе своих учетных данных в ваше приложение. OAuth великолепен (чертовски лучше, чем OpenID), но не был разработан для iPhone. Он создан для работы внутри веб-браузера. Я думаю, что документы API Foursquare лучше всего говорят об их схеме OAuth для клиента Mobile / Desktop (отличается от того, что они хотят, чтобы вы делали для веб-приложения): «Мы предоставляем этот механизм в предположении, что если пользователь установил ваше приложение на своем оборудовании они настолько доверяют, что передают свои аутентификационные данные в foursquare. "

3 голосов
/ 09 марта 2010

Подавляющее, подавляющее большинство пользователей не поймут или не позаботятся о различии. Делайте все, что делает их жизнь проще, или - при прочих равных условиях - ваша жизнь легче. И до тех пор, пока вы заслуживают доверия (вы не фишингуете или проверяете свои учетные данные, верно?), Вы будете предоставлять хороший опыт, а не облажаться. В этом случае я бы использовал UIWebView.

1 голос
/ 11 марта 2010

Для лучшего взаимодействия с destop и мобильным приложением мы должны использовать xAuth: http://docs.google.com/View?id=ddkz8b2q_76d95356mz

1 голос
/ 09 марта 2010

Я уже реализовал это как набор классов (с открытым исходным кодом).Не стесняйтесь взглянуть: http://github.com/bengottlieb/Twitter-OAuth-iPhone

0 голосов
/ 31 мая 2017

Начиная с 31 мая 2017 года и далее, выбора не осталось. Мы ДОЛЖНЫ использовать Safari, поскольку Google теперь не поддерживает OAuth через UIWebView. Для получения дополнительной информации см. эту ссылку.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...