My website's landing page redirects to authentication provider domain [not controlled by me] where credentials are entered and on success returns to reach Home Page (back to my domain).
All this is fine except if I check the referrals of HomePage on Adobe Analytics it shows me the URL's from authentication domain only. I understand Adobe uses javascript 'r' variable to populate, how can I re-populate it with original referral?
In general, you can override the reported referring URL by populating s.referrer
Ideally the auth server's redirect directive or server-side scripting in general should be configured to carry over the original referrer.
But you said you don't have control of that server, so your only other option is to push the current url to a cookie and then read the cookie on next page view and push that to s.referrer.
But.. this may not be a perfect solution for you, depending on how exactly your site flows.
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.
I'm setting up a site whose entire purpose is essentially a landing page. This page will create a cookie when the user fills out the proper form. To handle cookies I'm using this jquery plugin.
My problem is, I have a separate site that should only be able to be viewed if the user has the cookie from the first site (the landing page). So far, in my testing, I have been having trouble since the cookie that I set at my landing page doesn't appear on the other site. The landing page is being tested on localhost, but the site that requires the user to have the cookie before viewing is live on the internet.
Here is how I set the cookie:
$('#submit')[0].addEventListener("click", $.cookie("test-cookie", "test-value"));
Then, at the other site I have something like this to check the cookie:
var cookie = $.cookie("test-cookie");
if (cookie != null && cookie != "") {
console.log("TRUE");
} else {
window.location = "http://www.thelandingpagesite.com";
}
Now, I'm not sure if the problem is with cookies (I don't know if they can be so easily transfered between sites, as far as I am aware of, they exist on the Users computer), or if I'm just setting it up wrong. Any help would be greatly appreciated! Thanks.
As far as I am aware, one site (www.example.com) cannot retrieve cookies from a browser for another site (www.Second-example.com).
It would be a major security breach if this was allowed as it would be very easy for someone to steal your cookie and gain access to your accounts and personal details.
I am afraid you are going to have to use some mechanism other than cookies.
You could store their IP as you suggest in a a comment on another answer. Just be aware that anyone on that Lan could access the page... for example if a student in a school fills out your form... the whole school would have access to the page you are trying to restrict.
Cookies are stored by the user's browser, but they are stored with a reference to the site that set them.
Site A cannot set a cookie for Site B.
Cookies are used to (among other things) store preferences. Allowing any arbitrary site to set a user's preferences for any other arbitrary site would invite vandalism.
Cookies are set for a specific domain or set of subdomains. They can be readable across multiple subdomains, so it would be possible to set a cookie for domain '.domain.com' that would be sent along with all requests to 'www.domain.com', 'landingpage.domain.com', etc.
If ultimately you would be having your landing page and the page they are be sent to on the same root domain, this would be possible.
It doesn't seem like authenticating a user is an issue with your question, you merely want the user to visit Site A before they can visit Site B.
This question might be of some use:
Cross domain iframe content load detection
On Site B you could have an Iframe pointing to a page on Site A which in turn loads an Iframe pointing to a page on Site B. If the Iframe pointing to Site A doesn't have the cookie, it could pass that information to the Iframe of Site B (by loading a different page perhaps), which when loaded could then call parent.parent.cookieNotSet() (or whatever you decide to call that function) so that Site B would redirect to Site A.
I hope that makes sense. It's a big workaround, but required to get around cross-domain issues. All of this would obviously require that JavaScript is enabled on the browser but what browser doesn't have JavaScript enabled nowadays?
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?