I'm currently working on some lightweight code to correctly wrap usage of the Facebook Unity SDK for some client applications, and I've run into a minor problem, wherein the Facebook Unity SDK docs suggest that I shouldn't be doing what I am. Basically I want to know if what I'm doing is right.
To preface - the documentation for FB.Logout suggests that a client app should never really need to call it, as it will log the user out of facebook globally, in contradiction of their expectations. (See https://developers.facebook.com/docs/unity/reference/current/FB.Logout)
In my code when I receive an error from facebook which could mean the token has been invalidated, I ping off a simple request which should always succeed if the user's token is still valid. If this fails, I invoke FB.Logout, because without doing so, calling FB.Login again will simply fail - the user's token will remain the same, and the Login call will succeed.
Behaviourally everything behaves as I would want - calling FB.Logout just clears the local state and lets me go back to my 'initialised but not logged in' situation.
Basically, I want to know if this is expected behaviour, and whether, contrary to the documentation, this is the correct case for calling FB.Logout.
Cheers,
Jeremy
FB.Logout will log you out of Facebook and your app on the web.
On mobile, it will sign out from your app.
This is by design, and your implementation is correct.
On Web, this method will log the user out of both your site and
Facebook. On iOS and Android, it will log the user out of your
Application.
On all the platforms it will also invalidate any access token that you
have for the user that was issued before the logout.
cf. https://developers.facebook.com/docs/unity/reference/current/FB.Logout/
Related
a little background:
I have an hotspot page wich integrate with facebook login oatuh. The app runs on facebook api v.2.4 and uses node/express/passport to handle the login process
The only option i pass to the oauth fb page is display: touch, so the login page works fine without cookie support
the issue:
since a few days , only on osx 10.11/cna the login can't be processed because of no cookie support in CNA (this should mean that fb ignores the display option, in this case only)
the same request made from a ios device from within the cna works fine
I've already confirmed the display option is actually send, so my best guess is that fb started overwriting/ignoring this option. Also I can't find any reference in the fb api docs anymore (except for display=popup in the manual login page)
Any hint about this ?
thanks
g
Not sure if you still have this issue, but I can confirm facebook login definitely works end to end inside the CNA on 10.11. The CNA does allow cookies, what it doesn't allow is access to existing cookies in safari or access to localStorage and sessionStorage.
If you have your FB sdk configured with cookies=false, this may well be your issue. When set to false I believe the sdk is then attempting to use local storage.
The other thing to check would be what you have in the walled garden list. We have just got to the bottom of this issue after a lot of frustration. Allowing certain CDN networks actually causes iOS to complete it's internet check and no longer think it's behind a captive portal. I added an answer here https://stackoverflow.com/a/41273984/4427589.
As I said, I can confirm it definitely works end to end inside the popup.
Cheers
Paul
I have Facebook's SSO working properly in my iPhone app and most of my users have not been experiencing any issues. However, a small number of them have been reporting errors with Facebook Connect and not being able to create an account. After an email exchange with one, we determined that the app permission toggle under Settings->Facebook was somehow set to disallow my app from using Facebook.
I have since added an error message telling the user this might be the case but my question is how did this switch get toggled in the first place? It would seem that a user would have to manually toggle this switch, right? I also looked for an API method that might do this e.g. rejecting Facebook SSO the first time a user saw the dialog asking for permission; I could not find any such code.
Any ideas? I'm hoping this problem will solve itself with the error dialog I've put in but if possible, I'd like to remove this issue altogether.
As far as I know, using the native dialog with iOS6 and rejecting the permissions request (the first one, at least, not sure about requests which are asking an existing user for more permissions) will toggle that switch
If you need to debug, try uninstalling the app from your facebook profile (a HTTP DELETE request to /<USER ID>/permissions will do this, or you can do it in the facebook app settings), remove the iOS app, then install it and try to connect for 'the first time' again
I've been trying to get this to work for a while, but I've apparently missed something.
All I want is to have the latest 3 or so posts from my clients Facebook page to populate and animate in a screensaver that I am building using Flash (AS3).
So far, every time I try to bring anything in, it requires a complete oAuth login and account link, but it's only a one way exchange (read-only, absolutely no writing, posting or even linking, since it's a screensaver) I'm not even sure the client wants pictures or anything.
I am currently trying to use the facebook-actionscript-api, but there isn't an option for the "App Login" type of Authentication that would solve most of my problems.
I'm at wits end and about to have to tell my client it can't be done. At least they'll always have twitter...
I don't think it is possible to get facebook feeds without an accesstoken (even if they are public). So I guess you need to define an app within Facebook and add login stuff to your app so users can give permission to your app for basic access.
Maybe this article offers some help: http://www.adobe.com/devnet/facebook/articles/flex_fbgraph_pt1.html
I'm building an iPhone app that has some social features. I've managed to get the user to log-in to Facebook within my application.
I've also implemented a webview that loads a facebook iPhone-optimized page. What I now want to do is my user to be logged-in within the webview without having to log-in twice (once in the app and once in the webview)
I've tried a few things playing around with the access_token in the URL but it didn't work.
Does anyone know if it is possible to implement that and how to do it?
Thanks in advance for your help
Short answer: You're probably not supposed to be able to do that.
The idea is that your app should only store an authentication token that lets you do stuff as your app (e.g. post to the wall as your app). On the web version, the user is logged in to facebook and facebook additionally passes an authentication token to your website; on the iOS version, I think you never get the Facebook session cookie, and I'm pretty sure you need the Facebook session cookie to be logged in to the web side of things (especially since it's designed for the browser — logging out of Facebook logs you out of Facebook Connect on all sites).
There are loads of things you can do to work around this — it's trivial to just ask the user for a username/password (and the whole idea of a "trusted UI" inside a UIWebView inside your app is flawed, despite Facebook's claims).
The "right" thing to do is to implement everything using calls to the iOS SDK so you don't have to bother with the web side of things.
were you testing your app on the simulator or on the device? The reason i ask is because im trying to get the app to stayed logged into fb which it does, sorta...it still pops a fb dialog saying it logged in fine and the user has to click on an OK button.
I havent had time to test it on the device but i think it may have to do with the fact that with the OAuth 2.0, with 3.2.x or >...if the fb is installed, it uses the fb-app login but if its not installed it uses the safari web login.
Since simulator doesnt have the fb app installed, it actually uses the safari web login (i humbly deduced) which would otherwise store a cookie and maybe it doesnt do so on the simulator..dunno, im still looking for the answer on that one :)
I'm working on integrating Facebook with my iPhone/iOS application and I want to know if I'm understanding the nature of the login procedure correctly.
With the old Facebook SDK ('Facebook iPhone SDK'), when we needed to request authentication permission from a user a UIWebView would be displayed with a login prompt. With the new SDK ('Facebook SDK for iOS'), the SDK uses Apple's fast-app-switching feature to temporarily place the app in background mode and then load the iOS Facebook app or Safari to authenticate. Is this basically the gist of it?
I've experimented with authenticating my app via the new SDK's technique and due to the nature of my app, it just can't support backgrounding. Does this mean I have to use the old SDK to launch a UIWebView-based authentication? I think this implementation is a lot cleaner anyway. Will I run into any major disadvantages from doing this?
Check out this question and my answer: Iphone facebook connect example calls safari. I don't want to use safari
You can make it use the UIWebView always. Facebook is trying to make it so the user only has to log in once per device (through either the Facebook app or in Safari) but I didn't like this flow (especially on the iPad). Though I'd rather not muck around with the Facebook code, I did find commenting out a few lines to be a quick way of getting the old behavior back.
I don't believe this is the case.
The Facebook SDK that I'm aware of, available at https://github.com/facebook/facebook-ios-sdk doesn't do anything like you describe. Is this the SDK you're using? I believe the last major update to this SDK from the "old" facebook SDK was to add support for OAuth-style authentication. With this change they broke code compatibility so apps were forced to make changes to incorporate the latest SDK.
When you call 'authorize' in this SDK you pass the app id, the desired permissions, and a callback delegate for notifications of errors or success (did login, did not login, did logout). You can also set any access token that you might have persisted from a previous session. Facebook validates this access token, and if it doesn't exist or is invalid it presents a modal login dialog. I believe the content of this dialog is a web page. The SDK authenticates the user using OAuth and makes the auth-token available for persisting between sessions.
At no time is the app exited to run the Facebook app or Safari. I'm curious - what led you to believe this was the case? (Or, perhaps there is some other SDK out there I'm unaware of?)
Take a look on this page: https://github.com/facebook/facebook-ios-sdk
And look at Single Sign-On. That describes the above scenario with fast switching.