So, we've got two domains like this subsubdomain.subdomain.domain.com and subdomain.domain.com
We need to use separate social apps for these domains, 2 cookies are set, 1 for each domain. The have equal names so lower domain has access to both cookies.
The problem is that instead of taking its cookie, lower domain takes cookie from upper one.
I thought browser supposed to choose cookie with most specific domain for current but somehow it doesn't. Is there a way to handle such situations?
Related
If example.com contains multiple subdomains and all of it resides in a single UA property, assuming subdomain tracking is properly set up in gtm (IE cookieDomain is set to auto and the root domain is on the referral exclusion list for google analytics), should more than one _ga cookie exist on page load when visiting subdomains?
For example, my gtm snippet is included across all subdomains and it fires a pageview UA tag properly and I visit status.example.com, should I see a _ga cookie with an example value of GA1.3.605803990.1475857272 with the status.example.com domain scope and a _ga cookie with an example value of GA1.2.1926999794.1476293458 with the example.com domain scope?
Or should there always be one _ga cookie fixed at just the root domain? I'm trying to determine why my google analytics is still reporting self referrals for both my root domain and subdomain.
If you want to track your domain and subdomains within a single property there should be a single _ga cookie. To make sure there is just one cookie the cookie domain should be set to "auto" when you create the tracker
ga('create','UA-XXXXXXX-X','auto');
which will make sure the cookie is set at the highest possible 'level'. If you get the code from the GA property settings the "auto" setting should already be in there, if you create the tracker via Google Tag Manager you need to explicitly set this via the "set fields" option where you set the field name to "cookieDomain" (GTM has an autosuggest feature that will help with the field names) and the value to "auto".
We are using ColdFusion 9.0.1 and are having issues with the JSESSION cookie being shared between a domain and a sub domain. They are two different websites and we do not wish to share any session information between them.
How do I add a value to the domain field of the jsessionid cookie? I've seen some examples of people creating a second jsessionid cookie manually but I would rather stick to just one.
I don't think the domain is set on the cookie by default which should limit it to the same domain, perhaps someone has edited your jrun-web.xml file and hard coded a value (look for cookie-domain tag)? See http://livedocs.adobe.com/jrun/4/Programmers_Guide/techniques_servlet13.htm for more info.
Very simple question here. Knowing about cross domain cookie security, does the same apply to sub domains?
EG. Should I be able to read a cookie set on some.abc123.com from the sub domain of www.abc123.com?
Cookie domains are suffix matching, so cookies of www.abc123.com will not be sent on the site of some.abc123.com and visa versa.
To have cookies be sent on both domains you should use .abc123.com as the domain.
As an alternative set a cookie at the abc123.com level then set and read cookies from there.
see here
Setting cookies for multiple sub-domains
If I want my account holders to be able to have their own sub-domains and even their own domains altogether. Using NGINX as my proxy server, should I create domains for each one in my NGINX conf and have my clients point their domains there or is there reasons why this would be bad? Also, if I do that, how can I pass account-specific (account in Django DB) information in with the request (ie, request from www.spamfoosaccount.com to my server, so I proxy the request back to Apache, but how does my application know that it came from spamfoo's account unless I look at request.HTTP_HOST (which might be the best way, but I don't know until I ask). Thanks in advance.
To know from which domain a request is coming from, you have to use request.META["HTTP_HOST"].
However, do not rely on this value for authentication, it can be forged easily. Authentication should be done in the usual way with django.contrib.session. A request from a specific domain/subdomain should not have more privileges/rights, even when the request contains an authenticated session. Privileges should be given to users/groups of users, not to domains.
Note that browser sessions cannot cross second-level-domains (e.g. session cookie from foo.com wil not be sent to bar.com), it can however be a *.foo.com cookie for all subdomains (if you explicitly set it so).
Let your users point their DNS records to the IP of your server, let NGINX route the request based on the domain to your backend and do normal authentication in Django.
Your question:
how does my application know that it
came from spamfoo's account
I don't know the specifics of your application, but it shouldn't matter where the request came from, but who issued the request (e.g. an authenticated user). You should have a model/field that links your users to their respective domains. When a user is linked to only one domain, the application should assume the user came from that domain. When a user is connected to more than one domain, you can look at request.META["HTTP_HOST"]. If this value matches any of the domains, the user is linked to, it's alright, the value may be forged, but by a user that is linked to that domain nonetheless.
Does anyone know whether I can set a session value for the current domain, and use this session for another domain?
For example:
when I set session in domain www.aabc.com and I wish this session to work in domain www.ccc.com as well -- I click a button in www.aabc.com and change the header to www.ccc.com?
You can only set cookies for your domain (and other sites on your domain, like subdomains, if I remember correctly).
This is (mainly ?) for security reasons : else, anyone could set cookies for any website... I let you imagine the mess ^^
(The only way to set cookies for another domain seem to be by exploiting a browser's security hole - see http://en.wikipedia.org/wiki/Cross-site_cooking for instance ; so, in normal cases, not possible -- happily)
I had to set this up at my last job. The way it was handled was through some hand-waving and semi-secure hash passing.
Basically, each site, site A and site B, has an identical gateway setup on each domain. The gateway accepts a user ID, a timestamp, a redirect URL, and a hash. The hash is comprised of a shared key, the timestamp, the user ID.
Site A generates the hash and sends all of the information listed above to the gateway at site B. Site B then hashes the received passed user ID and timestamp with the shared key.
If the generated hash matches the received hash, then the gateway logs the user in and loads their session from a shared memory table or memcached pool and redirects the user to the received redirect url.
Lastly, the timestamp is used to be able to determine an expiration time for the provided passed hash (e.g.: the hash was only valid for x time). Something around 2.5 minutes is what we used for our TTL (to account for network lag and perhaps a refresh or two).
The key points here are:
Having a shared resource where sessions can be serialized
Using a shared key to create and confirm hashes (if you're going to use md5, do multiple passes)
Only allow the hash to be valid for a small, but reasonable amount of time.
This requires control of both domains.
Hope that was helpful.
You cannot access both domains sessions directly, however, there are legitimate solutions to passing session data between two sites that you control. For data that can be tampered with you can simply have a page on domain abc.com load a 1px by 1px "image" on xyz.com and pass the appropriate data in the querystring. This is very insecure so make sure the user can't break anything by tampering with it.
Another option is to use a common store of some kind. If they have access to the same database this can be a table that domain abc.com stores a record in and then passes the id of the record to domain xyz.com. This is a more appropriate approach if you're trying to pass login information. Just make sure you obfuscate the ids so a user can't guess another record id.
Another approach to the common store method if these two domains are on different servers or cannot access the same database is to implement some sort of cache store service that will store information for a time and is accessible by both domains. Domain abc.com passes in some data and the service passes back an ID that domain abc.com sends to domain xyz.com which then turns back to the service asking for the data. Again, if you develop this service yourself make sure you obfuscate the ids.