We are using Akamai to do A/B test, is there a way that Akamai can get different cache with some cookie value.
For example: suppose I have 2 applications App-A and App-B under www.example.com, is there a way that when request has cookie "to-A=true" then go to the cache of App-A, and if cookie has "to-A=false"? then go to App-B?
Thanks!
You could achieve this using Cache ID Modification behavior. You can enable the Include the following cookies action & mention your cookie name on the Elements to include field. Akamai will basically create 2 cacheID (ID's would be different though) for the resource & the cacheID will be constructed with the cookie name (&values if you say yes in Include values property). When the incoming request has these cookies set, then Akamai could serve the specific resource from the cacheID (that has the cookie value in its ID).
In your example, the Cache ID would be constructed like the below for the resource abc.js. The abc.js that came from Origin App A would be saved under to-A cacheID & the one from App B would be saved on the other.
X-Cache-Key:S/L/**/abc.js cid=_to-A=true_
X-Cache-Key:S/L/**/abc.js cid=_to-B=true_
Related
i want to create cookie based authentication depends on path ,
so simply for testing i have create two views and set cookies respectively
View 1 Cookie With globalLy available
View 2 Cookie With Specific
But the problem in both view only global cookie is available
View 1
View 2
You can see both cookie have same name but different path, but when we get cookies only global cookie is available
if i display request.META.get('HTTP_COOKIE')) then all cookie are display but not in request.COOKIES.get('last_visit')
please help, i have tested in php , it works fine but not in python django
The problem that you face relates partly to Django, but firstly to the properties of HTTP cookies mechanism itself.
A cookie valid for a path is also valid for all its subpaths (a query string doesn't matter). So last_visit cookie intended for / is also valid for /view2/. For specifics of the matching mechanism, defining whether a cookie is suitable for a path, see subsection "5.1.4. Paths and Path-Match" in RFC6265.
So both cookies are sent, and the order in which they are listed in Cookie: HTTP header is from more specific paths to less specifics ones. See over here in RFC6265.
Now, Django processes cookies from the header one by one and populates a plain python dictionary request.COOKIES, rewriting values when keys are already present. That is how your value for last_visit is rewriten when both cookies for both paths are sent in http request.
While Django processes cookies like that, though it would be more reasonable to only keep the first (not the last) value for the key as it relates to more specific path, you can fix the issue by only using the same cookie names for paths of the same level -- for /root/view1/ and /root/view2/, but not for /root/. Or You can divert cookie names with respect to http path like that:
import hashlib
cookie_name = 'last_visit%s' % hashlib.md5(request.path).hexdigest()
# ...
cookie = request.COOKIES.get(cookie_name)
# ...
response.set_cookie(cookie_name, cookie, path=request.path)
As the owner of domain example.com with many content what security risks arising from providing subdomain to third party company. We don't want to share any of the content and the third company would have complete control over the application and machine hosting the subdomain site.
I'm concerned mainly about:
Shared cookies
We have cookies .example.com, so there will be sent also in the requests to subdomain. Is it possible for us to point A record to reverse proxy where we strip the cookies and send the request to third party provider without them?
Content loading from main domain
Is it possible to set document.domain to example.com and do XMLHttpRequest to the example.com?
Cross site scripting
I guess that it would be no problem because of the same origin policy. Subdomain is treated as separate domain?
Any other security issues?
We have cookies .example.com, so there will be sent also in the
requests to subdomain. Is it possible for us to point A record to
reverse proxy where we strip the cookies and send the request to third
party provider without them?
Great idea, you could do this yes, however you will also need to set the HttpOnly flag, otherwise they would be able to retrieve them with JavaScript.
Is it possible to set document.domain to example.com and do
XMLHttpRequest to the example.com?
No, subdomains for Ajax are treated as a different Origin. See this answer.
I guess that it would be no problem because of the same origin policy.
Subdomain is treated as separate domain?
JavaScript code could interact with each other subdomains - but only with the cooperation of your site. You would also need to also set document.domain = 'example.com'; If you do not do this, you are secure against this threat.
See here:
When using document.domain to allow a subdomain to access its parent
securely, you need to set document.domain to the same value in both
the parent domain and the subdomain. This is necessary even if doing
so is simply setting the parent domain back to its original value.
Failure to do this may result in permission errors.
Any other security issues?
You need to be aware of cookie poisoning. If evil.example.com sets a non host-only cookie at .example.com that your domain believes it has set itself, then the evil cookie may be used for your site.
For example, if you display the contents of the cookie as HTML, then this may introduce XSS. Also, if you're using the double submit cookies CSRF prevention method an evil domain may be able to set their own cookie value to achieve CSRF. See this answer.
I'd like to set an HTTP cookie for my users, in order to not bother them with having to log in every time.
What I want to know is this: if I set the cookie at a page other than the homepage for my website, then will that cookie be available when the user comes to my homepage the next time?
More generally, is it the case that I can set the cookie at any page of my website, and the cookie will be available to me whenever I want?
Thanks!
Cookies can be configured to be available on specific subdomains, specific paths and specific protocols (HTTPS only, for instance). Without you telling which language you're using, it's hard to tell the default behavior of your local Set-Cookie function, but I believe that most often, the default behavior is to make the cookie available to all subdomains and all paths.
So yes, if you set a cookie on a random page, it should be available to the home page, too.
Yes - once you set a cookie it will be accessible from the server as long as it is stored in the user's browser (hasn't expired or been deleted).
I found that if the cookie is being set via Javascript, then this can be determined via a simple parameter.
The example JS code (from here) sets a cookie, that is available across the site
$.cookie('the_cookie', 'the_value', {path: '/'});
We are developing a Kohana Framework-based website with multiple subdomains, using the subdomain prefix value as the key for content and configuration filters...
This works great until a user with an active session to one of the subdomains visits a parent domain... Then they get a combination of BOTH cookies from each domain, which can lead to undesireable effects (parent domain settings inherited by subdomains).
For instance, I go to https://test.ourdomain.com and get a cookie with a session ID in it. All further requests to this URL or folders/files under this host have that cookie sent with the request in the headers. When I then go to https://sub.test.ourdomain.com, BOTH the cookie generated for that URL, PLUS the cookie generated for the parent url (test.ourdomain.com) is propogated. These cookies contain identically keyed information with varying values, and sometimes the values for the parent override the one for the child, producing undesireable effects on the child.
Preferably using Kohana's cookie settings, what can I do to limit the cookie propogation from parent domains to children?
You can set cookie settings in your bootstrap.php file.
By the looks of the documentation, you should be able to append Cookie::$domain = "test.ourdomain.com"; or Cookie::$domain = "sub.test.ourdomain.com"; to the end of your bootstrap.php file.
This should apply globally where ever cookies are used (including native and cookie-based sessions). You might have to clear your current cookies when making this change before noticing its effects.
Edit: Just realized how old the question is, hopefully this can solve any future questions.
Has anyone had a problem in running domain level cookies with Akamai implementation?
The site issues a domain level cookie which contains 2 values which are used by other apps.
With Akamai in the mix, the cookie never gets generated. When I take Akamai out of the mix, everything works fine. Not sure if anyone else has seen this behavior. I am not clear on how Akamai handles cookies.
Akamai, by default, strips cookies from cached resources.
The logic (quit sensibly) is that cookies are designed to be specific to each browser/user, so caching them makes no sense.
My advice:
1. Check if the resource in question is being cached. You can use the Akamai browser plugins for this
2. Think carefully why you would want cookies in a cached resource
3. If you are sure you do want these cookies, contact Akamai. They can change this behaviour for you
As an alternative, you can still cache those pages: you'd need to define the cookies in an uncached URL, which should be called inside the cached pages, for example, as a tag.
That way you can do redirects, AJAX calls, or DOM manipulation from JS depending on cookies from within cached pages.