I am building a guest wireless access for a pub. The idea is that users will be granted with internet access if they like they pub's website.
Now I was checking the requirements on facebook to check this and I found this:
Gate access to your app, or some content within your app based on
whether or not someone has liked a page.
NOTE: facebook wifi is not a solution for me hence I am using ubiquiti unifi AP
Does it means that I can't read if my clients like my page in order to allow them to use my wifi? is there a way around it?
If that's the solely purpose of the user_likes permission for your app you will very likely not pass the Login Review process.
Related
I've got incoming messages working via webhook, but what I cannot understand is how I make this available to other users.
I run a SaaS that's used by many different organisations, so I want to be able to give those organisations (who each have a subdomain on my domain) the ability to 'connect to facebook messenger', so that all of the messages to their facebook page (whatever that may be), come into their portal view on my platform.
The only way I can see this working, is by getting each user to register as a developer, and go through all the set up that I did to get my test example working.
But I must be missing something? What's the workflow to enable this, simply, so that users can connect in this way?
You can have multiple Facebook pages connected to your single Facebook app. But you would require permissions from Facebook for that. You can read about permissions here: https://developers.facebook.com/docs/facebook-login/permissions/
I have more than few clients that would like to add facebook connect to their landing pages (managed by me). They are too many and not enough tech-savvy to manually create ad appid for each of them.
So my only solution is to usa my own appid to add facebook connect to all my clients websites, but as far as I know, Facebook doesn't allow to simply use the same appid on any domain.
How can I solve this? I can't find any documentation to solve my issue. Does anyone have a direction for me?
This has been discussed a couple o’ times before already – but I mostly commented on earlier questions, so let me write the whole thing up as a proper answer, for future reference.
[paraphrased] Multiple-client Facebook login via one single app id
Does anyone have a direction for me?
You probably rather don’t want to do that.
It is not really possible to run one simple app one multiple different domains.
As a workaround for only a few domains, people used to specify different domains for the different platforms – Website, Page Tab or Canvas App, plus Mobile alternative for Canvas – without actually using any of those platforms besides Website, which made the app usable on multiple domains as a website app. But since Facebook introduced their login/permission review process¹, you can’t do that any more – they expect you to present actual functionality on all platforms you have configured in your app.
You can kind-off use one single app for login on multiple domains – if you are willing to use only the server-side login flow, and to redirect users to one “main” domain (that gets specified as the app domain in the app settings) to login, and then from there back to the origin domain.
But this has several drawbacks:
It’s not what you’d call a “white label” solution. If your clients expect it to look as if users where logging in via “their” app, it should stay on their domain. Individual branding, in regard to stuff such as app name, app logo that shows in the login dialog, etc., would also not be possible. Additionally, app attribution – the link that shows up under content shared/posted via the app – would only link users back to the main domain, and not to your customer’s.
You would not be able to use the JS SDK for client-side API requests, or even just to embed it to render any of the FB social plugins that require an app id – the SDK checks what domain it is “running on”, and can not be tricked to accept a domain that is not specified in the app settings.
There could be privacy issues. An over-exaggerated example: Just because I as the app user decided to share my photos or videos I have on Facebook with your customer Our-Holy-Mother-of-Christ-Bakery.com, does not necessarily mean I want to share them with your other customer, amateurs-doing-all-kinds-of-nasty-stuff.xxx as well – but if they shared an app id for login purposes, I automatically would. Have fun writin’ the Privacy Policy (which is mandatory if you use FB login functionality, and FB also automatically checks if your app has got one) for that scenario ;-)
Finally, and most importantly: All your customers would be “sitting in the same boat.” If one of them, or in turn their website users, would publish spam via your app id, so that Facebook blocks it, login would not work any more for all of your customer’s websites. And if you decide only then, that setting up an individual app for each of your customers would be the better way to go, they would not be able to recognize their existing users any more, because of user ids being app-scoped since API v2.0 was introduced – so if users logged into this new app, that app would see a totally different user id. (And to rely on an email address as an identifier is risky, too, because you will not get one from the API for every user; for example if they registered using their mobile device.)
Edit: Plus, app/domain insights, as luschn mentioned in his answer.
¹ Yes, the review process has made it more laborious to set up multiple apps for multiple clients. But for apps that do the same stuff/use the same permissions in the same manner, you can refer to an earlier successfully reviewed app id to speed up the process a little. Also, screenshots of how f.e. posts made via the app look on timeline, and what UI components are used, as well as screencasts that you include in your submission could probably be used with little to no alteration.
Apps are not meant be used on several different domains, you will have to create a new App for each domain, i´m afraid. You can use the different platforms in the App settings to use different domains, but there are only a few so it´s pointless. Just create some screenshots and a tutorial for your clients, that´s how it is usually done.
Btw, it would be weird to authorize an App on a website, and the same App would allow you to be authorized on all other client websites. Also, insights are per App, so your clients may want to see their own insights and not the global insights of all domains together.
Many is not defined but i think for being a smart developer you need to create new app_ids for every project you need to use facebook connect. Just my opinion. It also allows you to monitor alot of stuff.
I have an app that can be accessed on mobile phones, both iOS and Android. The app has a social component to it, so people are sending data to and from my server.
I also have an interface for this app that will be accessible through Facebook.
When logging into the app via mobile device, using the native app for that device, one can just log in with standard username and password.
However, obviously if a user accesses the app in Facebook, they will expect to already be logged in since they are already logged into Facebook.
So I need to make it so that my app can take a log in from Facebook, pretty much automatically (?) for users who are coming at it from within Facebook.
Further, it's possible (dare I say "likely"?) a user might access the interface from both Facebook and one of the mobile versions of the app. In which case I need to be able to ensure that the username/password authentication they use on the device points to the same account associated with their Facebook login.
So... all that said... what kind of Facebook authentication should I be studying and implementing.? I'm looking at their documentation right now, and like all documentation, it's not easy to grasp. There is server-side (authentication code flow?) and client-side (implicit flow?), and authentication tokens, and I'm already a bit lost.
Also, I assume Facebook's approach is to want to take over my login in process completely, not live side by side with my mobile-device-only login, but I'd like to make sure users have the option of not using Facebook authentication if they don't want.
Can someone point me in the right direction for how to do this? Basically let me know which part of the documentation I should be focusing on.
And are there any gotchas I should watch out for?
Your server will receive a signed request when your app on facebook.com is loaded; from this you can find the FB uid of the user.
If you obtain the FB uid for users of your mobile device clients you'll be able to match your app's accounts between mobile device & facebook.com clients.
The bottom of the main authentication docs page gives links to further documentation for different client types. The main mobile authentication page has side-bar links to tutorials & SDKs for iOS & Android. Alternatively you could use the server-side OAuth flow as your devices have browsers that support this.
Once you've completed authentication on the mobile device it's simple to obtain the uid.
You can also use the Facebook authentication flow instead of your own username/password authentication.
I have a button in my iOS app to share the currently viewed content on facebook. I'm deciding on the permissions needed for the app, it only needs to write links to the stream, and I don't want to access any of the user information, including the Basic Information, that seems enabled by default. How do I disable this?
You can't, connecting through Facebook Connect implies the user allows you're app to access minimal informations
http://developers.facebook.com/docs/authentication/permissions
Your friend connects to Facebook and checks "remember me".
Facebook creates a cookie on the browser.
Your friends goes to the bathroom.
You steal your friend's cookies from his browser and its data.
You go home and make these cookies with that data.
Assuming Facebook does not associate cookies + IP, you can gain access to the Facebook page. Edit: True, Facebook does not check for IP.
Now, let's take a look at Facebook Connect. This is the key.
User "connects" by pushing the button.
Facebook sets a cookie on the browser , which your application backend will read from to determine if the user is authenticated. Then, you associate this FB-cookie-id with the user in YOUR system.
If your system does not check for IP, then theoretically faking the cookie will allow you access into the application that used Facebook Connect. Which then you can gain access to the application,
Is it valid to say that you should check for IP when doing Facebook connect to add a level of security? But even if you do, some people have commented about IP Spoofing.
#everybody who says "Physical Access":
Yes, I agree that the concept of physical access makes this question trivial. However, this is a hole that the APPLICATION must be aware of. Sure, the Facebook profile/worthless application wouldn't matter much...but What if the application was a banking system? All I am saying is that if Citibank or Bank of America used "Facebook Connect" (which would be stupid, but let's assume), then this method would prove to be an easy way to access their account.
Therefore, Facebook Connect should NOT be used with anything "important". Right?
Another option is, after your friend goes to the bathroom, you can steal his wallet and use the cash inside to bribe his girlfriend into giving you his Facebook password, thus rendering all of his applications using Facebook Connect vulnerable.
Then you have the issue of going around WiFi networks, which would make the "remember me" option useless
No. To steal your friend's cookies you need physical access to the machine, and if you have that everything stored there is vulnerable to you. There's nothing Facebook can, or should, do to prevent this.
There are plenty ways that you can follow in order to hack a facebook account.
For example you can begin by learning a few basic hacking methods(there are thousands of them) and try to combine them together.
Some of them are:
Keylogger.
Denial of Service (DoS\DDoS)
Waterhole attacks.
Fake WAP.
Eavesdropping (Passive Attacks)
Phishing.
Virus, Trojan
ClickJacking Attacks.
etc
Ofc, there are a lot of tools there on the internet that might help you, some are free(most of them are fake) and some are paid(few of them are fake. There was a website for example in Netherlands that was for free and it managed to hack 3 accounts out of 10 for me depending on their security protection. You can give it a try here.
Good luck!