![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Entry tags:
more cookie adventures
Yesterday while trying to get my LJ login to persist, I accidentally deleted all cookies. And now today it was Dreamwidth that kept logging me out! Even though I didn't change my Dreamwidth exception, which was working before.
Obviously I didn't completely understand how the cookie exceptions work, so I read up on them, and did some more testing.
Cookie settings - from http://blog.teamtreehouse.com/how-to-create-totally-secure-cookies :
(so apparently "HttpOnly" has nothing to do with HTTP vs HTTPS, but "Secure" does.)
The DW cookies have Path = "/", Domain = ".dreamwidth.org", HttpOnly = true, Send for = "any type of connection" (which must mean Secure=false). So the cookies are sent from the browser to the DW server when any DW page on any subdomain is opened, and for both http and https.
But the Exceptions are what control how long the cookies are stored.
Based on the following pages, you don't have to enter subdomains (and you shouldn't use wildcards) in the URLs for Exceptions - all subdomains are included by default. Ie. "yahoo.com" includes "mail.yahoo.com".
https://bugzilla.mozilla.org/show_bug.cgi?id=336207
https://bugzilla.mozilla.org/show_bug.cgi?id=286499
Based on my testing, HTTP and HTTPS exceptions are mutually exclusive. Adding an "http://" exception will only work on pages using HTTP. Adding an "https://" exception will only work on pages using HTTPS. So if you've set your cookies to be deleted when closing the browser, but you want your "ljloggedin" cookie to persist whether you've logging in from an HTTP *or* an HTTPS dreamwidth page, you need to have "Allow" exceptions for both "http://dreamwidth.org" and "https://dreamwidth.org". Whereas if you are careful to only login from the HTTPS pages, you should only need the latter.
Obviously I didn't completely understand how the cookie exceptions work, so I read up on them, and did some more testing.
Cookie settings - from http://blog.teamtreehouse.com/how-to-create-totally-secure-cookies :
Path: The default value of “/” means every request will get the cookie, while “/forums/” would limit the cookie to just that path.
Domain: Setting “www.example.com” will mean only the exact domain “www.example.com” will be matched, while “.example.com” will also match again any subdomain (forums.example.com, blog.example.com).
Secure: tells the browser (or other http clients) to only send the cookie over SSL connections.
HttpOnly: tells the browser that it should not allow JavaScript to access the contents of the cookie. This is primarily a defense against cross site scripting.
(so apparently "HttpOnly" has nothing to do with HTTP vs HTTPS, but "Secure" does.)
The DW cookies have Path = "/", Domain = ".dreamwidth.org", HttpOnly = true, Send for = "any type of connection" (which must mean Secure=false). So the cookies are sent from the browser to the DW server when any DW page on any subdomain is opened, and for both http and https.
But the Exceptions are what control how long the cookies are stored.
Based on the following pages, you don't have to enter subdomains (and you shouldn't use wildcards) in the URLs for Exceptions - all subdomains are included by default. Ie. "yahoo.com" includes "mail.yahoo.com".
https://bugzilla.mozilla.org/show_bug.cgi?id=336207
https://bugzilla.mozilla.org/show_bug.cgi?id=286499
Based on my testing, HTTP and HTTPS exceptions are mutually exclusive. Adding an "http://" exception will only work on pages using HTTP. Adding an "https://" exception will only work on pages using HTTPS. So if you've set your cookies to be deleted when closing the browser, but you want your "ljloggedin" cookie to persist whether you've logging in from an HTTP *or* an HTTPS dreamwidth page, you need to have "Allow" exceptions for both "http://dreamwidth.org" and "https://dreamwidth.org". Whereas if you are careful to only login from the HTTPS pages, you should only need the latter.