A web application I'm currently developing needs users to be able to sign in via Facebook OAauth. However the problem is, all these users are behind a firewall that blocks access to facebook.com (company policy). We've looked into several solutions to get around this, like;
Putting a (squid) proxy between Facebook and the users. This could solve the problem since squid supports fine grained regex-based ACLs. However, most of the Facebooks OAuth strategy runs on www.facebook.com and inspecting PATH_INFO to whitelist specific paths is not possible if the users use HTTPS (which is mandatory).
Adding a proxy-like site in the DMZ of the firewall, which just passes and alters the urls/Facebook request. This obviously isn't the way to go either since it would basically mean users leave their credentials at our server, which is against Facebooks terms.
Loosen up the firewall a bit to just enabling IP addresses needed for OAuth authentication, but as far as we could find out there isn't a dedicated IP or subdomain just for authentication (it would be nice if graph.facebook.com would provide something like this).
Any ideas for alternate solutions? Is this even possible at all?
No, because the OAuth Login process for the API works by sending the user to a HTTPS URL on facebook.com you won't be able to easily distinguish between the traffic needed to setup the login to your app and other traffic to Facebook.com
You'll have the same problem trying to verify a Facebook user by use of a social plugin like the Like Button - you can't easily separate the traffic for the plugin and other traffic to facebook.com
Related
A web application I'm currently developing needs users to be able to sign in via Facebook OAauth. However the problem is, all these users are behind a firewall that blocks access to facebook.com (company policy). We've looked into several solutions to get around this, like;
Putting a (squid) proxy between Facebook and the users. This could solve the problem since squid supports fine grained regex-based ACLs. However, most of the Facebooks OAuth strategy runs on www.facebook.com and inspecting PATH_INFO to whitelist specific paths is not possible if the users use HTTPS (which is mandatory).
Adding a proxy-like site in the DMZ of the firewall, which just passes and alters the urls/Facebook request. This obviously isn't the way to go either since it would basically mean users leave their credentials at our server, which is against Facebooks terms.
Loosen up the firewall a bit to just enabling IP addresses needed for OAuth authentication, but as far as we could find out there isn't a dedicated IP or subdomain just for authentication (it would be nice if graph.facebook.com would provide something like this).
Any ideas for alternate solutions? Is this even possible at all?
No, because the OAuth Login process for the API works by sending the user to a HTTPS URL on facebook.com you won't be able to easily distinguish between the traffic needed to setup the login to your app and other traffic to Facebook.com
You'll have the same problem trying to verify a Facebook user by use of a social plugin like the Like Button - you can't easily separate the traffic for the plugin and other traffic to facebook.com
Can the Stack Overflow community sanity-check this for me?
I am working on a project that involves two components: an iOS app and a mobile website. It's for a product that will interact pretty heavily with Facebook. The website is hosted on Heroku.
From iOS land, my intention is to use the Facebook iOS SDK for authentication and then hit the web API with the user's access token at https://[myappname].herokuapp.com. Since Heroku offers piggyback SSL when using the herokuapp.com domain, and the user won't be seeing this URL anyway, I figure that's fine. And this way the request is encrypted, so the access token should be safe.
From the mobile website, users will log in using Facebook, at which point my understanding is that the access token will be in their cookies, which my server can then access without having to exchange it back and forth with each request. By this reasoning it seems to me I can just stick with regular unencrypted http:// URLs for the website (and therefore use my custom domain name without having to pay a monthly fee for Heroku's SSL Endpoint add-on).
Does this all make sense? I will be the first to admit my understanding of a lot of this stuff is in serious need of an upgrade. But for now I'm just looking for someone who can tell me, "No, you're totally overlooking/misunderstanding XYZ" or "Yeah, this is how it's generally done."
Facebook advises that you should not take a dependency on their cookie format. They have stated that the cookies are "an implementation detail" that they may tweak at any time with no notice given. You should not directly access the token or other user info directly from the cookie. I personally have had some bad experiences trying to get user information directly from the cookies, mostly due to timing -- they were not always there or updated when I expected them to be.
Client-side, you should either get the access token from the Javascript SDK via FB.getLoginStatus or other method that returns the access token, and then post it up to your server. This should really be done using ssl otherwise you are susceptible to network packet sniffing where a black hat could grab the token and be able to use all of the privileges the user granted your app.
There is also a server-side option as well which hits at ssl endpoint on Facebook's servers to return an access token.
References:
"Cookies are an implementation detail": https://developers.facebook.com/blog/post/624/
Authentication docs: https://developers.facebook.com/docs/authentication/
Website login via Facebook works totally fine via HTTP.
We have enabled SSO for our Google Apps Domain. When users try to access "http://mail.google.com/a/domainname.com" they get redirected to the custom SSO Sign in page url. But when url http://google.com/a/domainame.com is accessed users are able to login to google apps users hub without being redirected to SSO sign in page url. As per my understanding, this kind of login should be only enabled for administrator of domain. Why is it happening for normal users of our domain.
How can we redirect http://google.com/a/domainname.com" url to custom sso sign in page. Please help. Thanks in advance.
You can't block people from logging into Google through 'local' credentials, if they know them: they need this for access via mobile devices, where you can't be redirected to a web page for SAML SSO, for example.
The normal solution is to change the password to something the user doesn't know.
Further, if you force 2-factor authentication for your users, this means a user can have one-time passwords for their mobile devices and still have an account password they don't know.
The www.google.com/a/yourdomain.com url points to google cpanel, which can never, ever be restricted through custom SSO, as this is your only recourse to disable SSO. If anything goes wrong, you need to hit that url to turn off SSO or change SSO settings.
If you wish to restrict access to cpanel, please look into organizations restrictions / superuser privileges; you can restrict cpanel superadmins to only one or two trusted admins.
If you wish to have only a single admin account with access to cpanel, but want to give some cpanel features to regular users, check out some third party apps in the google marketplace; gPanel is especially good as it gives you fine grained control over who can access what. Couple that with SSO, and you get a complete logging / monitoring / access control solution.
My facebook application is redirecting to https can somebody help me i dont have ssl on my server and i want to keep the app on http, with https it generate the following error
SSL received a record that exceeded the maximum permissible length.
(Error code: ssl_error_rx_record_too_long)
Here is an article that gives a good run down on this, Hyper Arts Blog.
It appears that facebook is going to encourage secure browsing and the only way to avoid end user warnings is to set yourself up with a secure site.
You have setup your facebook app to have a secure canvas. Try removing it.
Also, your own personal facebook settings probably have https usage enabled... https://www.facebook.com/blog.php?post=486790652130... Try unchecking that settings.
If you don't provide a secure canvas the user's (who has requested facebook use https when possible) browsers is supposed to ask the user if they can go to the unsecured site... but we are talking facebook here so expect the unexpected.
I am working on a site that uses Facebook Connect for user login/creation. I have a development server which is used for QA, and I'd like it to be password protected. We wanted to use HTTP basic authentication, but that seems to break Facebook Connect (it falls in a loop). Does anybody know why that may be happening?
I believe that basic authentication is done on a browser basis, and all the communication between Facebook and our site is done in the browser of the user. What could be the problem?
Facebook Connect uses iFrame inside iFrame hack to overcome cross domain boundaries limitation (see http://wiki.developers.facebook.com/index.php/Cross_Domain_Communication for details). My guess is that when Facebook redirects to the callback page (xd_receiver.htm) it fails because later requires basic authentication.
More information needed on the "falls in a loop". But based on your question, from what I've read is that facebook connect will create a random password on account creation, and if they are logging in over basic auth, it will need to be changed to match up(http://www.boonex.com/unity/forums/topic/facebook-connect-error-.htm)
But you don't specify if that's the way you are using FBconnect.
Are you requiring basic auth to get to the point of FBconnect account link/create?
Or are you using FBconnect to create the login for the basic auth?
How are you requiring basic auth? Server type?
Does everything work without requiring basic auth?