I want to login with FaceBook from mobile devices(WebView).
I'm trying to login using the example from this tutorial https://developers.facebook.com/docs/facebook-login/login-flow-for-web
But I'm getting the following error
Given URL is not allowed by the Application configuration.: One or
more of the given URLs is not allowed by the App's settings. It must
match the Website URL or Canvas URL, or the domain must be a subdomain
of one of the App's domains.
According this manual, I must using faked redirect_uri for oauth service to login from WebView
https://www.facebook.com/connect/login_success.html
Now, connection string looks like this
https://www.facebook.com/connect/ping?client_id=188978851312862&domain=&origin=1&redirect_uri=http://static.ak.facebook.com/connect/xd_arbiter.php?version=29#cb=fc2b211fc&domain=&origin=file%3A%2F%2F%2Ff3b6d7ef1c&relation=parent&response_type=token,signed_request,code&sdk=joey
And if you go to this link, you will get the error. But if i change redirect_uri to this
https://www.facebook.com/connect/ping?client_id=188978851312862&domain=&origin=1&redirect_uri=https://www.facebook.com/connect/login_success.html&domain=&origin=file%3A%2F%2F%2Ff3b6d7ef1c&relation=parent&response_type=token,signed_request,code&sdk=joey
It will succeed.
Is it possible to set faked redirect uri and use standart JS API?
UPD: Actually authorizing complete well, but the API's event (auth.authResponseChange) doesn't fires. The problem in origin parameter in redirect_uri which is set to file:// when I loginnig from mobile's WebView.
As far as I can tell, the advice to, if you're in a WebView, "redirect to https://www.facebook.com/connect/login_success.html" is so that it will redirect there, with some auth keys "also in the url" and then you can parse them and close your WebView, so basically a one time callout, FWIW. My other guess is that origin is there, but not actually checked or used by them [?]
In terms of "using the standard JS API" I think you can but it's non trivial see here.
https://developers.facebook.com/docs/facebook-login/manually-build-a-login-flow/v2.0 Are you using this? If you need any more help give me a buzz, just made one of these
Related
I am using a node webshot library to take a image of an web site say at http://x.y.z.com/blah . If the website exists I get a nice image. If the website does not exist I may or may not get an error. If I get an error case I can use a default image. However, I am finding out that some domains are being redirected to the infamous Domain selling sites or a "search for" Domain site. For example, http://notawebsite.com.org is redirected to http://www.com.org/?notfound=notawebsite.com.org. I have also checked dns to see if I can invalidate the site ahead of time but it resolves fine ( to the www.com.org address ). So is there anything I can do to determine if a url site is redirected to one of theses Domain search/selling sites?
Is there a standard way of Identifying 'Domain not Owned' sites when using http/https?
No, not really. In the example you cite, the server for http://notawebsite.com.org returns a 301 redirect. It seems to me that you just decide that if you're getting a redirect to a different domain (and not just a redirect to a different page on the same domain and not just a redirect from http to https on the same domain), then the URL you were attempting to access is apparently not active on its own.
There is no standard way to know whether the site you are redirect to is just a domain seller vs. an actual active domain. You could manually investigate a bunch of sites you get redirects on and teach your code how to identify some common domain sellers doing this, but that would be a somewhat unending task that probably need regular human intervention to tell the difference between a real site and a domain selling site. You could, in the end, built up a blacklist of domain seller's domains and refuse to catalog any URL that redirects to any domain on your blacklist. But, it would probably take some manual intervention to build and maintain the blacklist.
You also have no way of knowing for sure that all URLs on a given domain where you're getting a redirect do a similar redirect, but you can certainly say that the URL you tried to get the snapshot from is not directly active on its own. If the user goes to that domain in their browser, they won't see any content for that domain in their browser because the redirect will change the URL.
So is there anything I can do to determine if a url site is redirected to one of theses Domain search/selling sites?
Build your own blacklist of reseller domains that show up in redirects like this. Then whenever you attempt to request a page URL for purposes of grabbing a webshot and you get a 3xx status code back from the request, you check the redirect domain to see if it is on your blacklist.
I'm writing a new JavaScript based Web app, which I need to secure in the following specific manner:
I should only allow for my app's index.html to be served if the request for it comes from a specific site.
By doing that, I will be forcing my users to go to that specific corporate site first, which will require for them to authenticate. Once the user is logged onto that site, they are provided with a link to my app. If my app's index.html is requested in any other way, beside following that corporate link, I would like to redirect the user to that corporate site.
How can this be accomplished?
You can use document.referrer to get the referral page. Once you get that from your corporate site you can probably put in some logic to redirect to the corporate site if it doesn't match where you're expecting.
Something tells me this isn't the best way to handle user authentication, but I'm new to that aspect.
Note: I'm on my phone, so excuse lack of code tags for that tiny bit up there.
Set a variable to the document.referrer().Then check the condition properly to determine if the referrer is in the proper page and if its not do a redirect..
I'm implementing a Google+ Sign-In for our web service, and stumbled on "Authorized JavaScript Origins". Our clients have web addresses either as a sub-domain of our main domain, or as a custom domain name. Since the login page is under that sub-domain (or custom domain), and in order to make the Google+ Sing-In button work, that custom domain/sub-domain should be (manually) entered in the "Authorized JavaScript Origins" list (with both http and https).
Does anybody know a way to do that automatically (through some API maybe)?
If not, then how do you do it?
Not sure if there is an API for this. At first glance I don't see one. The alternative (aside from manually adding domains all the time) is to use a hidden iframe on each site - this iframe would come from your domain and would be the only thing that calls google services. The main sites would communicate with the iframe (postMessage) to tell it what to send google. This of course, opens up a security risk (anybody could load your iframe into their page and do bad things on your behalf) so you'll want to make sure that the iframe code refuses to do anything unless it's running within a page on a known-good domain.
You can also have a common URL which all subdomains point to when trying to log in with Google. Then have this URL redirect to your actual Google login path. Beats having to deal with an iframe this way.
Finally I made it to work, however there may be some fixes to apply.
So a server is host for many domain and subdomains (childs) which all of them needs google sign-in and there is a main domain (parent).
I implemented a general login page on parent which childs open this page via window.open() as popup. As client is in a popup, it is very likely that auth2 cannot open another popup, so the parent will do the google auth with {ux_mode: 'redirect'} parameter as gapi.auth2.SignInOptions.
Process will continue to your callback page which you provided as another gapi.auth2.SignInOptions parameter which is redirect_uri and is on parent.
On this page google may have provided you the golden id_token which you must authenticate this token on your server. And this was the main twist which you should use this information to create a token on your server which parent asked server to create, but send it to child on client side (for example via query parameter) to use it for later usage.
I will happily take any advice for security leaks or any comment which may ease the process just a little.
There are few questions with same name but none of them intended to ask what I have in my mind. So we initialize FB js sdk with only app id. It's easy to know other web site's app id by looking at their facebook initialization source code. One might think that it's possible that a hacker might try to initialize FB JS SDK with other's app id and try to get their user access tokens. But facebook doesn't allow such stuff. You have to load js sdk from the same domain you specified in the site url property in Facebook Developer Apps page. So the question is how do they know that the jsonp whatever calls coming from the right client? It's not safe to that checking in client side since people can copy and modifty the javascript as they wish. So it has to be server side checking. I can only think of "referer checking" but I feel it cannot be considered a safe way.
Well, I'm not sure so this is only speculation..
First of all, when making an http request the HTTP referer header is added, and so when you load the sdk the url from which you're making the request is added as a referer.
Facebook can check on their servers where the request was originated from and compare that to what they have for the app settings.
It's possible of course to modify this header when making the request, which is why you don't get any error just by loading the sdk for an app if you're in the wrong domain.
The error will only occur when you try to interact with the sdk, for example trying to execute the FB.login method will open the auth dialog pop-up which will show the following error message:
An error occurred. Please try again later.
If you check the url of this auth dialog (which the sdk constructs) you'll notice these two query string parameters:
domain=THE_DOMAIN_OF_THE_PAGE
redirect_uri=FACEBOOK_URL which will contain origin, domain and relation=opener
What (probably) happens is that facebook checks the domain against the app settings, if it's ok it presents the user with the auth dialog, when he finished the process he is redirected to the redirect_uri.
Since the redirect_uri opens in the pop-up it can only communicate with it's opener if they are both in the same domain, a facebook domain which no one can have on his page other than pages served from facebook.
When the sdk loads it adds an iframe into the fb-root container which loads a facebook js which is loaded from the same domain as the redirect_uri, because of that the pop-up window can communicate back with the iframe and inform it with the auth response.
After the iframe got the response, the pop-up closes and the iframe informs the loaded sdk in the main page of the response.
I'm not sure which technique they use for that communication, but you can easy find more info about that by googling "cross domain iframe communication".
That's how I see it, but I can't be sure.
You can check the code for the js sdk # github if you want to really know what's going on.
Here is a permalink for a tweet on twitter:
https://twitter.com/#!/917thebounce/status/144914597537787904
Notice the hash symbol in the url. When I enter the url into Facebook's debugger tool:
https://developers.facebook.com/tools/debug/og/object?q=https%3A%2F%2Ftwitter.com%2F%23%21%2FHYPERCRUSH%2Fstatus%2F144920720378568704
it appears as though twitter is sending back a 301 Redirect to a permalink that DOESN'T have a hash symbol. When I view the original link in my browser, I don't get the 301. I understand that the reasoning behind sending the redirect is so that it gives Facebook a proper url to scrape data from.
a) How might the twitter application know to redirect the Facebook scraping application but not a normal user visiting via a browser?
b) More importantly, how in the world might twitter know which non-hash url to redirect to? Since to my knowledge an http request does not include anything after the hash symbol, i.e. doesn't twitter only receive a request to https://twitter.com/? I must be wrong here.
Actually, its a "shebang" and is used to javascript based navigation. This is a google thing, so urls with shebangs actually can be indexed.
You should be able just to remove it and the request it through facebooks debugger tool, which means you should be able to send https://twitter.com/917thebounce/status/144914597537787904