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
Related
My application is writing/reading files to/from Google Drive. Before I can access the files I need to get a token that would be passed with the request. I am using googleapis node package.
The flow is as this:
get auth url:
the front end sends request to my api
my api requests the auth url from Google with
(new google.auth.OAuth2(
creds.GoogleDrive.clientId,
creds.GoogleDrive.secret,
'http:localhost:3000/ifr'
)).generateAuthUrl({scope: 'https://www.googleapis.com/auth/drive'});
the received url looks something like this:
https://accounts.google.com/o/oauth2/v2/auth?scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fdrive&response_type=code&client_id=<...>&redirect_uri=http%3A%2F%2Flocalhost%3A3000%2Fifr
this url I return to the front end and set the source of the iframe to it
If a user has already gone before through the steps of consenting to my app accessing their Drive, then google redirects to the provided url, i.e. http:localhost:3000/ifr, in this case, and adds code query sting parameter, which I then pass to my api to get the token from google. This token is later used to create google.drive object that gives access to the drive (this part works fine, though maybe there is a way to avoid going back and forth between client and api?)
If a user hasn't consented yet, then the above url loads google's page where the user has to click through a few confirmation buttons and after they agree to everything, google redirects to http:localhost:3000/ifr?code=.... And this is where I have a problem. In this scenario google's confirmation page wouldn't load in the iframe, it gives me a "broken" page. I don't see a way to distinguish between the url that would load the consent vs the one one that redirects with code, they look the same, so I can't load one in the iframe and the other in parent.
How are these pages different? Why one is ok to be loaded in the iframe and other one isn't? Maybe I am doing this all wrong and the whole authentication can be done server side?
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 was attempting to use Tableau online embeddable charts with OneLogin using the session_via_api_token method.
I am able to retrieve token from backend and pass it to frontend. As mentioned here, the only way to call session_via_api_token is to POST a form.
The issue I'm facing is, after the form's POST, I'm redirected to /apps page of OneLogin. Is there any way I can specify a return url, or make the default behavior to redirect to one particular page(of my domain) after login.
What I want to achieve is hit session_via_api_token request of onelogin and redirect it back to my custom reports page where I've embedded a couple of tableau reports.
Sorry about the lack on detailed docs on this (it's coming!)
This endpoint relies on the HTTP_REFERER header being set and should redirect back to that URL.
Not sure what browser you're using, but that should be set automatically during the POST operation to our endpoint. It's worth noting that this does have to be done on the user's browser in order for us to establish an SSO session.
e.g. User's browser does a POST to our site with the token - We establish a session and set the cookies for our domain then we redirect back you your login 'facade'
To simplify things, we will be adding CORS support for this endpoint, and that work should be completing soon.
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
According to the Facebook API documentation, most of the work is handled through javascript.
That means that all the processing is done, and then the front end checks if the user is connected to Facebook/authorized. right?
My question is:
Suppose a user goes to my site for the first time ever.
He clicks on "facebook connect". The javascript verifies him as authentic, and it "redirects" to another page on my server. From then on, how do I know that the user is actually authenticated to my website, since everything is done on frontend?
I think this is correct, but aren't there some security issues..:
-After user clicks Login, Facebook redirects to a page on my site. AND they also create a cookie with a specific "Facebook ID" that is retrieved only from this user. My backened will "read" the cookie and grab that ID...and then associate it to my userID.
If that is correct...then it doesn't make sense. What if people steal other people's "facebook ID" and then forge the cookie? And then my backend sees the cookie and thinks it's the real user...?
Am I confused? If I am confused, please help me re-organize and tell me how it's like.
Facebook Connect uses a clever (or insane, depending on your point of view) hack to achieve cross-site communication between your site and Facebook's authentication system from within the browser.
The way it works is as follows:
Your site includes a very simple static HTML file, known as the cross-domain communications channel. This file is called xd_receiver.htm in the FB docs, but it can be named anything you like.
Your site's login page includes a reference to the Javascript library hosted on Facebook's server.
When a user logs in via the "Connect" button, it calls a function in Facebook's JS API which pops up a login dialog. This login box has an invisible iframe in which the cross-domain communications file is loaded.
The user fills out the form and submits it, posting the form to Facebook.
Facebook checks the login. If it's successful, it communicates this to your site. Here's where that cross-domain stuff comes in:
Because of cross-domain security policies, Facebook's login window can not inspect the DOM tree for documents hosted on your server. But the login window can update the src element of any iframe within it, and this is used to communicate with the cross-domain communications file hosted on your page.
When the cross-domain communications file receives a communication indicating that the login was successful, it uses Javascript to set some cookies containing the user's ID and session. Since this file lives on your server, those cookies have your domain and your backend can receive them.
Any further communication in Facebook's direction can be accomplished by inserting another nested iframe in the other iframe -- this second-level iframe lives on Facebook's server instead of yours.
The cookies are secure (in theory) because the data is signed with the secret key that Facebook generated for you when you signed up for the developer program. The JS library uses your public key (the "API key") to validate the cookies.
Theoretically, Facebook's Javascript library handles this all automatically once you've set everything up. In practice, I've found it doesn't always work exactly smoothly.
For a more detailed explanation of the mechanics of cross-domain communication using iframes, see this article from MSDN.
Please someone correct me if I'm wrong - as I am also trying to figure all this stuff out myself. My understanding with the security of the cookies is that there is also a cookie which is a special signature cookie. This cookie is created by combining the data of the other cookies, adding your application secret that only you and FB know, and the result MD5-Hashed. You can then test this hash server-side, which could not easily be duplicated by a hacker, to make sure the data can be trusted as coming from FB.
A more charming explaination can be found here - scroll about halfway down the page.
Same issues here, and I think Scott is closer to the solution.
Also Im using "http://developers.facebook.com/docs/?u=facebook.jslib-alpha.FB.init" there open source js framework. So things are a little different.
For me, via the opensource js framework, facebook provides and sets a session on my site with a signature. So what I am thinking is to recreate that signature on my side. - if they both match then the user is who he says he is.
So basically if a user wanted to save something to my database, grab the session signature set up by facebook and recreate that signature with php and validate it against the one facebook gave me?
if($_SESSION['facebookSignature'] == reGeneratedSignature){
// save to database
}else{
// go away I don't trust you
}
But how do you regenerate that signature? preferably without making more calls to Facebook?