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?
Related
My web site uses magic links for login, however, I have a problem on mobile (not sure about Android - haven't tried yet, but the problem exists at least on iOS): when a user receives the email say in the GMail app, the link opens in the embedded browser, meaning that cookies will not be passed to the "real" browser.
Is there a way to ensure the link in the email opens in the real system browser and therefore cookies are stored permanently?
(Essentially browser session isolation on iOS breaks a lot of things on the Internet, so surely there is a workaround?)
After some research: no, it is not possible to detect you are in an embedded browser, neither is it possible to enforce opening a link in the system one. Makes sense from security point of view.
However, I was asking the wrong question. The problem of a magic link login is solved differently: when starting a login process you can set a session cookie and create an associated DB record for it, marking it as blocked, i.e. not logged in.
At next step, when the magic link is opened in whatever browser you unblock the session in the DB. At this stage you can replace the login cookie with a real one, e.g. JWT, or continue using it as your main auth token.
If the user then returns to the real browser, you check the login cookie and act accordingly, keeping in mind that it may not be the browser where they validated the magic link. At this stage you can, again, replace the login cookie with your real auth cookie knowing that the session has been validated already.
I'm not entirely sure this is 100% safe, need to think about it more but at first glance it does look safe and seems to be pretty much the only way of handling magic links on mobile.
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.
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.
Is it possible to delete a cookie on one site when being redirected to that site from another site? Or is that impossible due to security restrictions?
Site A has a login form that submits to and logs in as Site B. When the user logs out from Site B after using Site A's login form, Site B forwards them back to Site A. Is there any way for Site A to delete a cookie on Site B without access to Site B's backend/code?
No, not if site A and site B are on different domains. There is a domain attribute that can be set in the Set-Cookie header, but this must be either an exact or partial match for the current domain. By partial match I mean that it is possible for foo.example.com to set a cookie for example.com but not for ample.com.
Source RFC 6265 (HTTP State Management Mechanism):
When the user agent "receives a cookie" from a request-uri...
If the canonicalized request-host does not domain-match the
domain-attribute:
Ignore the cookie entirely
Bear in mind that a cookie deletion is really receiving a cookie with an expiry date in the past so that is why the above still applies.
Site B would have to implement a mechanism to allow this to happen.
AFAIK this is not allowed for - as you guessed - security reasons.
Take a look here for further details: http://en.wikipedia.org/wiki/Same_origin_policy