I have an iframe where I display some of the user's Facebook information. When my server generates the content for the iframe, it checks for responses from Facebook indicating that the access-code has expired, and sets up the re-auth sequence to occur inside the iframe, where it will be the least noticeable to the user. If, however, the server detects that the user is not logged in, it will bounce out to a new browser window to lead the user through sign-up.
Lately, I've noticed my iframe tends to go blank. The issue appears to be that occasionally the Facebook APIs will report an access-code as expired when, in fact, the user is not even signed in. Attempting to renew the access-code causes Facebook to redirect to the login page. But the login page is served with 'X-Frame-Options:DENY' Header, so the browser just refuses to display anything in my iframe. I don't have any control over this process once I invoke the URL to renew the access code, and since the content in the iframe is on a different domain, the hosting page can't even detect when this situation has happened.
Anybody know of a solution to this? Ideally, the Facebook APIs would more accurately report on expired access tokens, but failing that, it would be nice if I could set the login page to be redirected to a new window.
Related
I am attempting to implement a simple Facebook login flow for a web application using HTTP redirects, as detailed at https://developers.facebook.com/docs/facebook-login/manually-build-a-login-flow/v2.2.
For the purposes of making this question generic, let's say the application URL is www.example.com/app.php. On the application page, there is a link which directs users to Facebook's OAuth endpoint, where ideally:
they log in to Facebook (if not already logged in) and approve my application permission to access their public profile
they are then redirected back to my application's URL along with some extra parameters appended (e.g. www.example.com/app.php?code=...&access_token=... if the login was successful, or www.example.com/app.php?error_reason=...&error=...&error_description=... if login/app approval was unsuccessful)
The Facebook OAuth endpoint is:
www.facebook.com/dialog/oauth?client_id=12345&redirect_uri=www.xyz.com/app.php
where I have filled in the client_id and redirect_uri parameters with my application's ID and my application's URL respectively.
What actually happens whenever I access the link is that it immediately redirects back to my application's homepage - without ever showing a login dialog of any kind. This happens with Firefox and with Chrome - both when I am logged in to Facebook and when I am not, in normal sessions and in incognito sessions with no plugins enabled. From the browser inspector, I can see that the Facebook OAuth page is definitely requested but is straight away 302 redirecting to my application page with just a code parameter appended.
www.example.com/app.php?code=...
This also happens when the Facebook OAuth link is accessed from pages other than my application's URL (e.g. if I click the link from www.example.com/other_page.htm).
I am unsure what I am doing wrong here; the application URL (www.example.com/app.php) is approved on my app dashboard in as many places as I could find, and changing the request_uri parameter to any other URL results in an error page. I have also tried urlencode()ing my application URL before passing it in the request_uri parameter, but the result remains the same. I don't know what to try next as as far as I can tell I have followed Facebook's manual login guide as closely as possible.
I'm serving a list of events to my clients’ website. They include it via php/curl (rather than iFrame), so they can fully customize the CSS.
However, this means that I can’t use the Facebook API to find out wether a visitor of my client’s page is logged in to FB: The FB-API call needs to be signed by an application and shall only be called from the domain the application is associated with. (That would be my server’s domain, but the requests are coming from my client’s page.)
Back in the old days, accessing a user profile on FB would issue a 404 error, if not logged in.
<script type="text/javascript" src="https://www.facebook.com/pianojoe" onload="enable_social_links()" onerror="not_logged_in_to_facebook()" async="async"></script>
That was convenient, but FB took care :-/ of it.
I want to show FB-links for the events in my calendar only if the page visitor is logged in to Facebook.
My question: How do I find out if a page visitor is logged in to Facebook if I can’t determine the domain of the referring page beforehand, and therefore not use the Facebook API?
The Facebook PHP SDK has a (relatively new) method called getLoginStatusUrl.
It creates a simple URL that you redirect the user’s browser to, which takes them to Facebook, where his login status is checked, and then redirects them back to one of three different URLs of your app, that you can specify.
ok_session is the one that you would be mainly interested in here: “URL to return if the user is logged in to Facebook.”
(The other two are no_user for when the user is logged out of Facebook, and no_session for when Facebook themselves can’t figure out the user’s status, because there’s no user-specific FB cookies whatsoever set in their browser.)
So you could set ok_session to an URL of your application with an additional GET parameter like ?logged_into_fb=true (the other two options, if not specified explicitly, will then only redirect back to your app’s base URL) – and that way, when the user is redirected back to your app with that parameter, you know they are currently logged into Facebook.
Whether or not you are actually using the FB PHP SDK does not really matter – by looking at the source code of the method it’s relatively easy to figure out how the actual URL is build, so you could easily adapt that and use it without the SDK as well.
Situation: I am developing a facebook canvas app. Facebook is sending my sever a POST request with the signed_request each time that a page is render. Inside my app I have all my links with target="_top" because if I don't, facebook send my server a common GET without the signed request. So I cann't check the user info.
Problem: It is too slow! even if I am testing it in local, each click that I press takes 1 sec to render and my canvas becomes completely white and then the info is shown, It will be a bad user experience.
My tests: If I remove the target=_top and I point all my links' href to my server without the app.facebook.com/whatever, it loads very quickly.
My doubts: Is there any security issue with this? If I point all the links to my server (no apps.facebook.com) I can not check the signed request, I will only check it in the main page..
Any advice? any tutorial? Do I have any misundestanding of this? (It is my first facebook app)
Have you read the Server-Side Authentication tutorial?
You're doing it wrong.
Once the users lands in your app you should keep all links in the same frame, loading the entire window along with facebook is completely redundant.
What you should do:
When you get the POST with the signed request, decode it and check if the user is authenticated, if he is persist the data (token and such) somewhere (session, db, cache).
If he is not authenticated send him to the auth dialog as noted in the tutorial, when he gets back exchange the code you get (in GET) for the token (also shown in the tutorial), then redirect him to http(s)://apps.facebook.com/YOUR_APP and you'll be posted with the authenticated signed request, save it, etc..
Since you persist the data, in every request that is not POST or don't include the signed_request check your persistency choice for the data, and use it.
There should be only two times where facebook sends you the request, once it is POST when your canvas is loaded, the 2nd is when the user returns from the authentication dialog, in which you either get the code parameter or error in case the user declined the authentication.
Other requests should be from your app (inside the iframe) into the app servers.
JDL,
I believe you are querying the graph API at each request (and that's why you always need the signed_request). Is this right?
The graph API is pretty slow (~ 1 second/query) and you should use only when necessary. For example, when you first receive the access_token you should save it in your session and query the graph API to retrieve the respective facebook user info. But then you should put the info you need about this user in your session and only refresh it (using the graph API) when the signed_request access token is different from the one you have saved in your session.
The behavior of adding _top to the target of your links is ok and a good practice within facebook canvas.
When a user visits my site "www.mysite.com" I set a cookie for that specific user.
Next the user goes to Facebook, lands on an application tab and clicks the like button. An external page "www.mysite.com/facebooktab.html" is loaded into the Facebook canvas.
1. Now, do I have access from facebooktab.html to the cookie I set on www.mysite.com earlier?
2. Does the page loaded into Facebook show the same behaviour as when I would just visit www.mysite.com/facebooktab.html in my browser, except that when the page is loaded within Facebook I have some additional user properties available to me (since user is logged in in Facebook)?
The critical difference between the two scenarios is that when your page is loaded directly, the cookies you set/read are "first party" cookies; when your page is loaded inside the Facebook framework, the cookies become "third party". Each browser has its own set of rules, but they all apply different policies to third-party cookies versus first party cookies. You mentioned you are initially setting the cookie directly on your website (first-party mode), and then only reading it when the page is inside Facebook (third-party mode). Most browsers will allow that with no restrictions, as they only apply stricter third-party policies to the writing of cookies and not reading. The exception is Firefox, which lumps reading and writing permissions together. If a Firefox user has cleared the "Accept third-party cookies" box in their configuration, your page on Facebook will not be able to read the cookie you set earlier even though it was set directly on your website.
well i have used the facebook api couple of times. But last day i just came across a site which was really new to me. Heres the scenario
If a user is logged in at facebook and comes to my site, he will
automatically be logged in without asking him and also if user logs
out of my site he gets logged out of facebook. But the site i saw
yesterday, they had handled it perfectly, user dose not logs in their
site automatically and even if user logs out from their site, he does
not gets logged out of facebook.
So any help? what is this technique called? or any relevant help?
Best Regards
most site handled the login/authenication by using the login status of the user at facebook ends.
to do what u wants, simply add an additional layer of authentication / login status checking at your own site.
The site level login status is to be retained only for the current session. In other words, once the user went away from the site, the site level login status is gone. With this, when the user returns, you know that he needs to login again.
when the user logged out from your site, you only log him out of your site and do nothing about facebook login
Using the Facebook SDK it will likely tell you the user is logged out when not logged into Facebook, which in theory is the correct behaviour of the whole system, as Facebook want user's to always be connected to Facebook, I quote facebook:
As long as the user is signed into Facebook, they are automatically signed into your site as well.
So if they aren't connected to Facebook, you aren't connected to other sites. In a way it's a deterrant and increases Facebooks market.
But anyhow, it's likely the site you are describing are implementing their own authentican system rather than using Facebook's own SDK, or if they are using the SDK they are using it in moderation and understand about cookies/the above.
The flow to allow the user to be logged into Facebook but out of your site is as so:
When a user logs out of their site, it will unset session data for the site's own application, and also unset Facebook cookies, etc. That way the user is still logged into Facebook but out of your site.
When they try to log in again, Facebook will detect no cookies are available and hence will re-authenticate and pass you onto the url as passed during the authentication process. Your site will then login the user to the site's own application, setting any session variables, etc.
you need to check how you are handling the FB logins and sessions at your end..
my guess is you check the is login at your site and there are some access_tokens which are as per your app id in the cookies of your browser which are helping you to log in ..
and when logging out from your site you are explicitly logging out the user from FB as well
( thats what you are describing atleast )
you seem to be explicitly calling logout or clearing the cookies for fb app id ..