Whenever I login to one Google service, I am automatically logged in all their other websites on different domains.
What I want to know is how they are able to access the disparate cookies and sessions that belong on another domain.
I tried searching online but I couldn't find any information. I could probably pull out firebug and try to find out but I am sure someone here knows.
A Google Login works like this:
1) You login, normally at a login page that is under the Google.com/accounts domain.
1a) If you aren't on the Google.com/accounts domain, it is going to forward you there after you post the form. This can be found on sites like Blogger.
Once you arrive at the Google.com/accounts domain, they do two things
2) They set a cookie(s) that is specific to the Google.com/accounts domain, that are also only able to be sent over a secure connection. This is to verify your identity later on.
I say multiple because there are several cookies bound to the google.com/accounts domain. I believe that one of these is to make sure that all doesn't fail if secure connections aren't allowed
3) They set a cookie that spans all the domains using .google.com as their domain, because this will make the cookie available to any domain.
4) They forward you back.
5) If it is a site on a different domain, like blogger, they send along an authorization key in the URL. The page sees it, verfies it, and sets the cookie for a different domain. A technique like this can be seen using Google's Oauth.
Here is where that Secure Cookie comes in.
If you notice, whenever you go to a site after you close your browser, they forward you to the google.com/accounts path, where they reverify you under a secure connection, and then reset the subdomain-wide cookie. Then they send you back.
Furthermore, some sites like Google Adsense use the same technique as Google.com/accounts uses, by making a secure cookie on a specific path, and then using more global cookies to allow greater access.
Some of this is guessing, but given what a non-insider can see, I believe that is close to the truth.
Note: I literally spent like an entire month just browsing from Google Site to Google Site seeing how they did stuff. By upvoting this post, you are decreasing the sadness I have for having no life
Related
I have Google sign in button that opens new window for authorization. Can I get cookies from that frame? If the answer is yes, the next question "how?" :)
Picture below shows my cookies (localhost) and cookies that came from Google auth.
Nope, these cookies are from another domain. For security reasons, you can and never will be able to read cookies that are not from your domain.
Think about the consequences it would have if you could: people logging in on your website through some OAuth service for instance, would basically "lose" all the cookie data to your website's JavaScript context since your website happens to include some iframe/image/script from another domain. It would be able to read all cookie values and copy a login session for instance, which might be stored in it.
I have built a cookie consent module that is used on many sites, all using the same server architecture, on the same cluster. For the visitors of these sites it is possible to administer their cookie settings (eg. no advertising cookies, but allow analytics cookes) on a central domain that keeps track of the user preferences (and sites that are visited).
When they change their settings, all sites that the visitor has been to that are using my module (kept in cookie) are contacted by loading it with a parameter in hidden iframes. I tried the same with images.
On these sites a rewrite rule is in place that detects that parameter and then retracts the cookie (set the date in the past) and redirects to a page on the module site (or an image on the module site).
This scheme is working in all browsers, except IE, as it needs a P3P (Probably the reason why it is not working for images is similar).
I also tried loading a non-existent image on the source domain (that is, the domain that is using the module) through an image tag, obviously resulting in a 404. This works on all browsers, except Safari, which doesn't set cookies on 404's (at least, that is my conclusion).
My question is, how would it be possible to retract the cookie consent cookie on the connected domains, given that all I can change are the rewrite rules?
I hope that I have explained the problem well enough for you guys to give an answer, and that a solution is possible...
I am still not able to resolve this question, but when looked at it the other way around there is a solution. Using JSONP (for an example, see: Basic example of using .ajax() with JSONP?), the client domain can load information from the master server and compare that to local information.
Based on that, the client site can retract the cookie (or even replace it) and force a reload which will trigger the rewrite rules...
A drawback of this solution is that it will hit the server for every pageview, and in my case, that's a real problem. Only testing that every x minutes or so (by setting a temporary cookie) would provide a solution.
Another, even more simple solution would be to expire all the cookies on the client site every x hour. This will force a revisit of the main domain as well.
Can someone please help me to find a solution to maintaining the session across subdomains.
The site uses fake subdomains for users, eg. (thisuser.mysite.com/). All the fake subdomains map to the main site (mysite.com) so there's a common database for everything.
The subdomains are used only for a couple of components(com_xxx) on the site. for other components the user is redirected to the main site via htaaccess.
The problem is when a user is redirected to mysite.com from thisuser.mysite.com and vice versa. Their session is not maintained. The user has to login back again.
I have tried updating the cookie domain in php.ini to '.mysite.com' but it doesnt seem to help.
Is it possible that the site may have auto-logins across all subdomains and main domain without any core hacks, assuming the solution lies in making cookies readable from all subdomains, irrespective of from where it's being set?
Thanks all, for your time and suggestions !
I'm not sure how you could do this....
Here is just an idea, it would rely on javascript...
WHen a user logs in using your login form... a hidden iframe would exist and javascript would post your login data to the login page of each domaine for your site. chaining them...
i dont feel its a safe thing tho... maybe im wrong...
u could use joomla's mootool framework to send an ajax requests to each domain...
Otherwise might want to check how joomla creates a session row in the database for each user on the site. maybe you can just create them for each domaine with 1 login. im gona check my mysql....
are you using joomla 1.5 or 2.5 ?
Otherwise i found this document for you:
http://docs.joomla.org/Multiple_Domains_and_Web_Sites_in_a_single_Joomla!_installation
okay, this was easy, I was testing on the local machine and it seems if domain doesnt have the dot, then the cookies are not handled well.
Just ensuring taht cookie domain is set to '.mysite.com' gets the job done
1. It is also recommended that you use the same joomla "secret" configuration value in the different websites as it is used to check the data exchanged between the different domains.
2. taht cookie domain is set to '.mysite.com' gets the job done
I am making app that takes a screenshot of a URL requested by the user. I want to make it as transparent as possible when sites that require username and passwords are in question.
For instance, if user wants to screenshot its iGoogle page, he will send the server URL but, the screenshot will not be the same as what he sees on his screen.
Is there any way to do this ? I guess that in such cases I will have to actually request screenshot from the user. Perhaps user can even deliver me his cookie for that domain.
Any thoughts ?
Ty.
Yes, in most cases you'll need user's cookies.
If site uses regular cookies, you can create bookmarklet that reads document.cookie. This will not work with httpOnly cookies which are used increasingly often for sessions.
Some sites limit sessions to certain IP, and in that case you can't take screenshot without proxying request through user's computer.
If you can get user to use bookmarlet, an interesting trick would be to read and send DOM to your server:
image.src = 'http://example.com?source=' +
escape(document.documentElement.innerHTML);
For HTTP authentication easiest solution would be to ask user for login/password.
Fogbugz-on-demand, 37 signals, and PB-Wiki all use sub-domains with custom url's for each group of users to access their login page. So it doesn't even seem possible for a user using those services to login to a generc login (that any user of the service could log into.)
At first I thought this was a terrible design flaw, but now I think this is a really good idea because of:
1) Additional security, it may not be much, but you now need 3 pieces of info: 1 sub-domain url, 2 login, 3 password
2) You can let the same login log into different accounts by the subdomain url.
3) This lends itself to more isolation, load balancing, and easy deployment since you can have the subdomains running under different servers in more isolation from each other.
4) You can gradually roll out changes to a certain set of sub-domains that are marked as BETA users before deploying them to all users.
Are sub-domain based logins for web applications the future? Are there pitfalls with this design approach I'm not seeing? Is it too confusing for non-programmer users to understand the sub-domain concept?
We went with a triple-element login instead. We ask for the username, password, and client-id. Same concept as the sub domains but there's a common login URL. That works fine too. However, I do see an advantage in the sub-domain process, you can brand the login page because you know the requested client. In our approach we can't brand the login page since we don't know the client until you submit the login page.