views:

221

answers:

3

Hey!

I am making an app to read news articles from a website on the iPhone. I would like to be able to share these articles on Facebook, using a password and email-address that was set somewhere programmatically (not using Facebook-Connect, mostly because I want the design to be the same, whether you log in to Twitter from the app or in to Facebook).

I have done this with Twitter's XAuth-support 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 be a lot easier)?
Is there any other way I can achieve what I want?

Thank you.


This question has NOT been resolved.


Bumpeti bump bump ;)

+4  A: 

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.
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
Facebook uses a webview to log in with, so I can't just call a function. **This answer has NOT resolved my question.**
Emil
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.
+1  A: 

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
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
A: 

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.

Tudorizer
I want a smooth design.
Emil