From mboxrd@z Thu Jan 1 00:00:00 1970 Delivered-To: chneukirchen@gmail.com Received: by 10.229.225.21 with SMTP id iq21cs82314qcb; Wed, 1 Dec 2010 15:59:33 -0800 (PST) Return-Path: Received-SPF: pass (google.com: domain of rack-devel+bncCLDl2s_FBxDjwtvnBBoEbJYTnw@googlegroups.com designates 10.100.239.5 as permitted sender) client-ip=10.100.239.5; Authentication-Results: mr.google.com; spf=pass (google.com: domain of rack-devel+bncCLDl2s_FBxDjwtvnBBoEbJYTnw@googlegroups.com designates 10.100.239.5 as permitted sender) smtp.mail=rack-devel+bncCLDl2s_FBxDjwtvnBBoEbJYTnw@googlegroups.com; dkim=pass header.i=rack-devel+bncCLDl2s_FBxDjwtvnBBoEbJYTnw@googlegroups.com Received: from mr.google.com ([10.100.239.5]) by 10.100.239.5 with SMTP id m5mr1513013anh.28.1291247972998 (num_hops = 1); Wed, 01 Dec 2010 15:59:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=beta; h=domainkey-signature:received:x-beenthere:received:mime-version :received:received:date:x-ip:user-agent:x-http-useragent:message-id :subject:from:to:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:sender:list-subscribe :list-unsubscribe:content-type; bh=cTdIIwjX4kcU1oAGa4tdimyQmnxo1svpNeeomtTVzwc=; b=BmOZm+FGmzcE7knyVB1ckZQwmEJ5am1HxySVepsGDKg1ASjSBBjrOcUfLwlwqOlUvt vSIPfm1bfaMc2/ATP2gqCKH1lCs3QN8zVhI7G4q73J8w/pdZgGkG7R0/HPV/PUJ0fVax a9H/geeTNqWduzeDtNYR/4j+mSQHYr/WySDgs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlegroups.com; s=beta; h=x-beenthere:mime-version:date:x-ip:user-agent:x-http-useragent :message-id:subject:from:to:x-original-sender:reply-to:precedence :mailing-list:list-id:list-post:list-help:list-archive:sender :list-subscribe:list-unsubscribe:content-type; b=XAdOuYMlqpf+nGMTMRRcHNfkUpW4i3Yb4KblHfnubrua3wBPaW/EmuGs9yOFrq1Y/m BUJALqcEJLoLK1DQ1eoolhNDtE0hJ7ZA+iBfhF8Vh1Ky4MZaaI1ZxyFeLYx6f7THHDlI VZrvqyVXXQ0UdyR4cdddLntCl0T8Xpr8To7yQ= Received: by 10.100.239.5 with SMTP id m5mr301677anh.28.1291247971177; Wed, 01 Dec 2010 15:59:31 -0800 (PST) X-BeenThere: rack-devel@googlegroups.com Received: by 10.100.26.21 with SMTP id 21ls1657151anz.2.p; Wed, 01 Dec 2010 15:59:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.210.9 with SMTP id i9mr299354ang.33.1291247970375; Wed, 01 Dec 2010 15:59:30 -0800 (PST) Received: by s4g2000yql.googlegroups.com with HTTP; Wed, 1 Dec 2010 15:59:30 -0800 (PST) Date: Wed, 1 Dec 2010 15:59:30 -0800 (PST) X-IP: 77.251.119.238 User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_5; en-us) AppleWebKit/533.19.4 (KHTML, like Gecko) Version/5.0.3 Safari/533.19.4,gzip(gfe) Message-ID: <90acafa6-979f-47a1-8a30-53066ba54267@s4g2000yql.googlegroups.com> Subject: Cookie on a subdomain can get lost/hidden on IE From: "Jan M." To: Rack Development X-Original-Sender: jmfaber@gmail.com Reply-To: rack-devel@googlegroups.com Precedence: list Mailing-list: list rack-devel@googlegroups.com; contact rack-devel+owners@googlegroups.com List-ID: List-Post: , List-Help: , List-Archive: Sender: rack-devel@googlegroups.com List-Subscribe: , List-Unsubscribe: , Content-Type: text/plain; charset=ISO-8859-1 This isn't really a bug in Rack but it is some really unexpected behaviour that caused a bug in my application that literally cost me days to figure out so I feel compelled to explain it here in case someone else goes googling for lost session cookies in Rails on Internet Explorer (which are handled by rack). Here is the scenario: - a user first visits "yoursite.com" and gets a session cookie - the user then gets redirected to "www.yoursite.com" and gets a different session cookie since www is a different subdomain - here is where it gets ugly: as long as they are on the "www' subdomain rack will now read the session store from "yoursite.com" but write to the session store for "www.yoursite.com" I looked into this but according to the RFC the order in which cookies from subdomains are returned is not defined so rack really can't be blamed, it just picks the first cookie it gets. The other browsers only return the cookie for the subdomain instead of both cookies like IE does. The mitigation is to either make sure you do the redirect to the "www" domain before hitting your app so it hasn't had a chance to set a session cookie, or you can explicitly set the domain in the cookie to ".yoursite.com" (note the leading dot) so one cookie will cover both domains. The message I got from users is "I can't log in" from less than 1% of my users. You can imagine it takes a while before I established what happened, because it only happens to individuals who somehow typed in the URL without www and only if they use IE.