Facebook войти в систему программно, используя OAuth / XAuth (?)

Question

Я создаю приложение, которое должно иметь возможность обмениваться историями с Facebook, используя пароль и адрес электронной почты, которые были установлены где-то программно (не используя Facebook-Connect , главным образом потому, что я хочу свойдизайн, будь вы входите в Twitter или Facebook из приложения).

Я уже сделал это с Twitter и XAuth, и это прекрасно работает.Есть ли способ, которым я могу добиться того же с Facebook или просто с помощью OAuth?( Или Facebook поддерживает XAuth , что сделает это намного проще?)
Есть ли другой способ добиться того, чего я хочу?

Answer 1

Теория заключается в том, что ваше приложение никогда не должно видеть пароль пользователя.

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

Поскольку у вас есть полный исходный код, достаточно просто вызвать функцию, которая выполняет вход с именем пользователя и паролем. Я не рекомендую это:

• Facebook, вероятно, не понравится, и он может отменить ключ API вашего приложения.
• Вы не должны хранить имена пользователей / пароли, если в этом нет особой необходимости, особенно в NSUserDefaults (который использует Settings.app), поскольку он полностью незашифрован.
• Setting.app не поддерживает поля пароля.
• Пользователю не нужно выходить из приложения, заходить в настройки, добавлять данные для входа и возвращаться к своему приложению. Это бит лучше с "многозадачностью", но не намного лучше.

Что не так с использованием обычного экрана входа в Facebook?

РЕДАКТИРОВАТЬ: Подробнее ...

• AFAIK, вы не можете надежно зашифровать NSUserDefaults, сохраненные в Settings.app. Вы не можете решить, в какой файл это записано (думаю, Библиотека / Настройки / com.example.myapp.plist). В iOS 4 вы можете установить NSFileProtectionKey = NSFileProtectionComplete, но у этого есть куча проблем:
  • Вы устанавливаете это внутри своего приложения. Пользователь может перейти к Settings.app перед запуском вашего приложения.
  • Хотя якобы возможно включить Library / Preferences / com.example.myapp.plist в ваше приложение zip / ipa, я не думаю, что возможно включить атрибут NSFileProtectionKey.
  • NSUserDefaults обновляет plist «атомарно», записывая новый plist в новый файл и переименовывая файл поверх старого. Новый файл вряд ли будет иметь NSFileProtectionKey = NSFileProtectionComplete.
  • В конечном счете, если вы передаете контроль над данными API, который не дает никаких гарантий безопасности, это небезопасно (NSUserDefaults, похоже, склонен оставлять много временных файлов, лежащих вокруг ...). Apple предоставила связку ключей специально для хранения паролей (есть даже несколько достойных примеров кода!); используйте это.
• Apple не рекомендует использовать Settings.bundle, а также собственный экран настроек - вы должны выбрать один или другой.

Answer 2

Для сайтов, использующих OAuth, таких как Facebook, вы пытаетесь обойти безопасность пользователей.Для простого описания OAuth, перейдите по этой ссылке: http://bit.ly/awynlU Короткая версия состоит в том, что Facebook отвечает за аутентификацию пользователя и делает это на своих серверах.Как уже упоминалось, теория состоит в том, что вы никогда не увидите пароль.

Хорошо, плохо или безразлично, то, что вы хотите сделать, должно быть предотвращено.Если это возможно, это нарушает модель безопасности, установленную на сайте - в данном случае Facebook.

Кстати, Twitter тоже движется к OAuth.Согласно имеющейся у меня информации: «Начиная с 31 августа все приложения должны будут использовать« OAuth »для доступа к вашей учетной записи Twitter».

Answer 3

Вы должны иметь возможность использовать более новый Facebook SDK для реализации единого входа в Facebook.Таким образом, если пользователь уже установил приложение facebook на своем устройстве, он уже вошел в систему, и это намного лучше, чем старая реализация всплывающего окна подключения.Для вашего приложения должно быть дано разрешение на доступ к своей учетной записи, но кроме этого уродливый экран входа в систему не используется.

Если приложение Facebook не установлено, оно отправляется в браузер.

Оба метода используют обработку URL-адреса для возврата к вашему приложению после аутентификации.

Подробнее об этом здесь: http://developers.facebook.com/docs/mobile/ios/build/#implementsso

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

Answer 4

Интересно, почему вы действительно хотите пойти с таким хакерским подходом? Пользователю необходимо войти в систему только один раз, чтобы получить токен OAuth2, и оттуда вы можете публиковать столько раз, сколько захотите, на Facebook, даже не прося пользователя войти на Facebook.