horror: MSIE will send all foo.com cookies to the subdomain too,
leaking
sessions (not just to Wordpress.com but to everyone because blog.foo.com
does not support HTTPS), and there’s no way to tell it not to
proposed workaround: serve blog.foo.com yourself, using Nginx,
HTTPS-only,
proxying to the hosted service (as foo.wordpress.com, which does support
HTTPS), and stripping out the parent-domain request cookies
Is there a way to do this with Nginx? A way to rewrite the Cookie header
to
strip out selected cookies?
Or is the only way out of this to avoid the subdomain cookie situation
altogether, either by running www.foo.com instead of foo.com, or by
abandoning the subdomain and using e.g. foo.com/blog/ instead?
On Fri, Aug 29, 2014 at 11:55:08AM -0400, gthb wrote:
horror: MSIE will send all foo.com cookies to the subdomain too, leaking
sessions (not just to Wordpress.com but to everyone because blog.foo.com
does not support HTTPS), and there’s no way to tell it not to
proposed workaround: serve blog.foo.com yourself, using Nginx, HTTPS-only,
proxying to the hosted service (as foo.wordpress.com, which does support
HTTPS), and stripping out the parent-domain request cookies
Is there a way to do this with Nginx? A way to rewrite the Cookie header to
strip out selected cookies?
With proxy_set_header you can change the header to any value,
including one with a particular cookie removed. The tricky part
is to construct new value for the original header. Something like
this should work:
set $new_cookie $http_cookie;
if ($http_cookie ~ "(.*)(?:^|;)\s*secret=[^;]+(.*)") {
set $new_cookie $1$2;
}
proxy_pset_header Cookie $new_cookie;
Yep, works like a charm, thank you! And two consecutive ifs to strip two
cookies works as well:
set $stripped_cookie $http_cookie;
if ($http_cookie ~ "(.*)(?:^|;)\s*sessionid=[^;]+(.*)$") {
set $stripped_cookie $1$2;
}
if ($stripped_cookie ~ "(.*)(?:^|;)\s*csrftoken=[^;]+(.*)$") {
set $stripped_cookie $1$2;
}
Cheers,
Gulli
Posted at Nginx Forum:
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.