I have a Facebook-App with a form to submit. I only want the users to be able to fill out the form once. What I would like to do is set a cookie + I was wondering if I can set something like a FB App-Cookie/token, that tells Javascript that I can't submit again?
Your app is just a regular iframe, so you can set cookies just as easily as if it were a normal website, outside of Facebook.
Don't forget, though, that you should never trust user input, so you will want to validate against multiple entries on the server as well — either by checking their Facebook user ID or some unique piece of information from your form (like the user's email address, for example).
But yes, you can easily set a cookie from the iframe. You should test to make sure that browsers aren't blocking it as a third-party cookie, though. You can test that easily enough by setting Firefox's preferences to disallow third-party cookies and so on.
Hope this helps!
Related
I have a MVC project with individual user accounts login in place. I want to integrate my application with facebook open graph. Facebook asks me to whitelist or allow access facebook crawler to view content without logging in. Here is what facebook officially asks for:
The Facebook crawler needs to be able to access your content in order
to scrape and share it correctly. Your pages should be visible to the
crawler. If you require login or otherwise restrict access to your
content, you'll need to whitelist our crawler. You should also exempt
it from DDoS protection mechanisms.
I just want to know is there any workaround for this?
Thanks
The default is for access to be allowed; you generally need to blacklist, not the other way around. All Facebook is saying here is that if your content is protected somehow and you actually want Facebook to be able to see that content anyways, then you need to simply allow the Facebook crawler to bypass whatever protection is in place.
However, there's no one simple answer for this. It's up to you to determine what protections if any you need to bypass and how to bypass it will depend on what the protection is. For something like Authorize, for example, you may need to create a custom attribute that looks for the crawler IP (I would not use the crawler's UA string as if some one figures out what you're doing, they could easily spoof that and gain access to protected areas of your site). Then, you could go ahead and treat it as authorized, even though there's no logged in user.
So I'm building my app around facebook oauth, and was hoping to use the fbsr_ token to identify logged-in users (so that the facebook-js stuff stays in sync with my site).
Unfortunately, it appears that these fbsr_* cookies are set to expire within a day. Which means if the user comes to my site a day later, they have no cookie and are shown a logged-out experience.
The facebook-js then runs, recognizes them, creates the fbsr_* cookie, and gives me a callback. I can choose to do a hard page refresh (rather jarring), or try to do fancy in-place ajax updating (tons of complex code, still slightly jarring). Is there a reason these cookies don't have a longer expiration so the user stays logged-in seamlessly? Most websites allow you to "remember me" when you log in to avoid constant cookie expirations, so I'd rather not have my facebook-enabled website keep logging me out.
Is there anything I can do about this? I suspect I can probably switch to serverside-oauth where I manage identity and cookie expiration myself (yes?). But it seems strange that clientside-oauth would have such a limitation, so I'm hoping I'm missing something.
Is there anything I can do about this?
No, not really.
The only way to determine, if a user is currently logged in to Facebook, is to look at the cookie set for the domain facebook.com.
The JS SDK is capable of doing that, because it runs client-side, and can make a cross-domain request to check if these cookies are set.
But there is no way to check for those cookies server-side from your domain – your server only has access to cookies set for your own domain.
I suspect I can probably switch to serverside-oauth where I manage identity and cookie expiration myself (yes?)
If your set your own cookies on your domain, you are implementing your own login system.
And even if you “fake” the cookies that the JS SDK sets under your domain, it would not bring the same results.
There might be a cookie on your domain, that says, “yes, user XYZ is logged in to Facebook” – but that would not have to be the case. I could have logged out of Facebook in the meantime, and your cookies would not reflect that at all. So whatever you’ll try to do next, like f.e. posting something on my behalf from your app, will most likely fail, because you only think I was still logged in to Facebook, but in reality you do not have a valid access token for me any more, since I am not really logged into Facebook.
The facebook-js then runs, recognizes them, creates the fbsr_* cookie, and gives me a callback. I can choose to do a hard page refresh (rather jarring), or try to do fancy in-place ajax updating (tons of complex code, still slightly jarring).
Those are your only viable options.
I have developed a facebook app (iframe). It works fine. But when user disables Third-Part Cookies in browser, the app goes into infinite redirection loop.
Please let me know if you need more info to help me out.
Are you sure you really need cookies? If so, unfortunately there is not really much you can do about this. If your app requires cookies to work, you're going to need the user to support third-party cookies. Check to make sure, though, that you're sending a P3P header. Some browsers require a valid P3P header in order to allow third-party iframe cookies at all, even if third-party cookies are enabled.
Exceptions:
If you only need one request, you can just rely on signed_request.
You could try using URL-based sessions instead of cookie-based sessions. PHP has some amount of built-in support for this, but with other languages/frameworks you might have to put some more work in.
I'm guessing that what you are doing is trying to redirect users to the OAuth dialog, and then that dialog is sending users back to your page, right? For that first request after an OAuth dialog, you should try to get authentication information out of the signed_request. Then you might want to store this in a server-side session and pass the ID of that around in either a cookie or query parameters. I believe the PHP and Python SDKs both do something like this. As I said above, if cookies don't work, you will need to figure out another way to persist state as users move around your application.
My honest recommendation? Try to detect if a user's browser does not allow setting a third-party cookie, and if it doesn't, then just throw up an error page explaining that their security settings will not let them use cool apps like yours.
if third party cookie is disable, session will not going to work as well as the session_id is store as cookie as well.
I am building a facebook canvas app and i am using the signed request parameter provided by facebook to check if the user has already authenticated the app. (by checking the presence of user_id field). If the user_id is not set then I redirect the user to a uthorization page (using top.location in javascript).
The problem is that, in my application I need to make internal redirects and then i can´t get signed request anymore.
Possible solutions:
1). Change the way i check if the user has installed the app . Get the current user (not sure if I need signed request anyway). Then use the graph api to check the permissions).
2). allways use client side redirects. (then I can allways get the signed request and it is also provides better navigation to the user because the top url change.) Not sure about the performance compared with iframe redirects.
What is the best option, in your opintion.
PS: I am using PHP SDK / symfony framework and the javascript sdk.
The most common way to handle this is to set a cookie to carry forward either signed_request or whatever subset of data from it you need, so it is available on all pages. You can do this directly or by using PHP sessions to store the data.
However I am personally of the opinion that cookies are a bad idea within iframe apps. For an alternate approach that may do what you need, have a look at http://www.braintilt.com/fbcookies.php .
I have a website based game that has login accounts that I want to integrate into facebook (not facebook connect, I want to use an iframe canvas page).
My question is how can I authenticate a user and how can I check if a user is coming from facebook or directly from the site.
I have been playing around with require_login() using the PHP library. My main fear is how can I authenticate that the GET parameters from facebook are indeed from facebook? If I can do that then I can store their facebook session id and Uid in a session as login credentials.
My other worry is that the GET variable may get passed as a reffer to an external link.
Finally... I find in some browsers that with require_login() that it breaks out of the iframe and gets into an eternal look continually adding additional authtoken's to the URL.
Hope someone can help
Yes you can create a app that works independently as well as facebook app. For the facebook you will have to use the facebook's iframe method to work under facebook.
You can verify the request comes from Facebook by verifying the signature in the same way that Facebook checks that API requests come from your application. With the PHP client library you can use the validate_fb_params() method of the Facebook class to do this automatically.
Bear in mind that session key's are temporary so the user will keep needing to authenticate with Facebook through your application otherwise the key expires within the hour. You may also run into a 3rd party cookie issue with Safari if you're hoping to store the session key in a cookie, and you'll need a compact privacy for quite a few other browser/privacy setting combinations as well. Something like:
<?php
header('P3P: CP="CAO PSA OUR"');
?>
in an include would do it.
And yes: the session key may be passed to external sites as in the referrer properties. It's just one of the security flaws that the platform currently has. The only way around that is either to redirect all external clicks through a handler which removes the referrer, or redirect on page load to strip the fb_sig_ss parameter out.