4

I am making an app that needs to be able to share stories to Facebook, using a password and email-address that was set somewhere programmatically (not using Facebook-Connect, mostly because I want my own design, whether you log in to Twitter or Facebook from the app).

I have done this with Twitter and XAuth already, and that works brilliant. Is there any way I can achieve the same with Facebook, or just regular OAuth? (Or does Facebook support XAuth, that would make it a lot easier?)
Is there any other way I can achieve what I want?

Cœur
  • 37,241
  • 25
  • 195
  • 267
Emil
  • 7,220
  • 17
  • 76
  • 135
  • **The bounty on this question was not awarded to anyone, because nobody actually solved my problem.** _Just in case anyone wondered.._ – Emil Oct 08 '10 at 17:48
  • Worth noting that this is against the TOS. – James Billingham Sep 19 '13 at 07:49
  • @JamesBillingham It is also from 3 years ago, hardly relevant as there are easy-to-use APIs included in iOS. – Emil Sep 19 '13 at 22:02
  • My comment was just as valid three years ago as it is now. SO comes up on Google results regardless of the age of the question, so it's useful information to a later visitor. – James Billingham Sep 26 '13 at 22:26

4 Answers4

5

The theory is that your app should never see the user's password.

In practice, since the code all runs in your app, it's trivial to get the user's password (and it's about as trivial to present a similar UI to grab the user's password).

Since you have full source code, it should be easy enough to just call the function that does logging-in with the username and password. I don't recommend this:

  • Facebook probably won't like it, and might revoke your app's API key.
  • You shouldn't be storing usernames/passwords unless you absolutely have to, especially in NSUserDefaults (which Settings.app uses) since it's completely unencrypted.
  • Setting.app doesn't support password fields.
  • The user should not have to exit your app, go to Settings, add login details, and switch back to your app. It's a bit better with "multitasking", but not that much better.

What's wrong with using the normal Facebook login screen?

EDIT: More details...

  • AFAIK, you cannot reliably encrypt NSUserDefaults as saved by Settings.app. You do not get to decide which file this is written to (Library/Preferences/com.example.myapp.plist, I think). In iOS 4, you can set NSFileProtectionKey=NSFileProtectionComplete, but that has a bunch of problems:
    • You set this inside your app. The user can go to Settings.app before running your app.
    • While it's supposedly possible to include Library/Preferences/com.example.myapp.plist in your app zip/ipa, I don't think it's possible to include the NSFileProtectionKey attribute.
    • NSUserDefaults updates the plist "atomically" by writing the new plist to a new file and renaming the file over the old one. The new file is unlikely to have NSFileProtectionKey=NSFileProtectionComplete.
    • Ultimately, if you give control of the data over to an API that makes no guarantees about security, it's insecure (NSUserDefaults seems prone to leaving lots of temporary files lying around...). Apple's provided the keychain specifically to store passwords (there's even some decent example code!); use it.
  • Apple does not recommend using Settings.bundle and also your own settings screen — you're supposed to pick one or the other.
tc.
  • 33,468
  • 5
  • 78
  • 96
  • I think that the regular Facebook-login screen is ugly. This is also partially why I want to do it this way. The passwords are now encrypted and stored somewhere safer. I still need to know how I can create a new Facebook-session with an email-address and a password, though. – Emil Oct 06 '10 at 09:43
  • Facebook uses a webview to log in with, so I can't just call a function. **This answer has NOT resolved my question.** – Emil Oct 06 '10 at 09:45
  • The complete source code is there. Dig around, issue the same HTTP requests that the web view does, and store the authentication token. It all happens in your address space, so there's no reason you actually need the web view (Facebook might try obfuscating the HTML to make programmatic logins harder, but there's no reason you can't work around this). – tc. Oct 13 '10 at 20:20
2

For sites using OAuth, like Facebook, what you are attempting to do is to circumvent user security. For a simple description of OAuth, check out this link: http://bit.ly/awynlU The short version is that Facebook is in charge of authenticating the user and does so on their servers. As tc has mentioned, the theory is that you never see the password.

Good, bad, or indifferent, what you want to do is supposed to be prevented. If it can be done, it's in violation of the security model the site has set up— Facebook in this case.

Incidently, Twitter is also moving toward OAuth. According to the info I have, "Starting August 31, all applications will be required to use “OAuth” to access your Twitter account."

CuriousRabbit
  • 2,124
  • 14
  • 13
  • I actually implemented Twitter today the way I want Facebook to be implemented, so it should work. I used XAuth, though. Facebook doesn't have the possibility of using XAuth, do they? – Emil Oct 01 '10 at 21:25
1

I wonder why do you really want to go with such a hackish approach. The user only needs to login once for you to obtain the OAuth2 Token and from there you can post as many times you want to Facebook, w/o even asking for the user to login with Facebook.

Tudor
  • 4,137
  • 5
  • 38
  • 54
1

You should be able to use the newer facebook SDK to implement facebook single sign on. This way if the user already has the facebook app installed on their device they are already signed in and it is a far better experience than the old connect popup implementation. Permission must be given for your app to access their account but other than that the ugly sign in screen is not used.

In the event they don't have the facebook app installed it will bail to the browser.

Both methods use the url handling to return to your app once authenticated.

Read more about it here: http://developers.facebook.com/docs/mobile/ios/build/#implementsso

In terms of implementing your own login screen natively instead, this is against Facebook's TOS as they want a consistent and familiar sign in platform to avoid prevalent phishing problems etc. They heavily push for educating their users to only provide their usernames and passwords to legitimate pages.

Daniel Bowden
  • 988
  • 1
  • 10
  • 23