When I set yahoo.com as is it will delete any thing that isn't exactly like that - sports.yahoo.com, mail.yahoo.com etc I've tried this on several sites. Is it possible to set a wildcard somehow for sites that have many subdomains?
Fantastic extension btw
Yes, that's how I designed it. If you have a tab open with yahoo.com then yahoo.com subdomains' cookies are not deleted. However, for the whitelist, it is more flexible where you selectively choose which ones of yahoo.com subdomains' cookies you want to keep. Possibly in the future I'll add RegExp support which will be a separate whitelist.
Thanks, I wondered if that was the case.17.02.2017, 11:42, "Kenny Do" notifications@github.com:Yes, that's how I designed it. If you have a tab open with yahoo.com then yahoo.com subdomains' cookies are not deleted. However, for the whitelist, it is more flexible where you selectively choose which ones of yahoo.com subdomains' cookies you want to keep. Possibly in the future I'll add RegExp support which will be a separate whitelist.
鈥擸ou are receiving this because you authored the thread.Reply to this email directly, view it on GitHub, or mute the thread.
I'd also like wildcards in whitelist. For GMail, I had to whitelist several subdomains for me to stay logged in.
Yes, wildcard is an essential thing for any list that involves domain names. Another option could be to add a checkbox next to each domain - "Include subdomains". Or just a global checkbox. Anyway you should give users a choice.
Possibly in the future I'll add RegExp support which will be a separate whitelist.
Why? It's just a list of domains, there's no need in regex.
For GMail, I had to whitelist several subdomains for me to stay logged in.
That shouldn't matter too much since you can export the whitelist later.
Another option could be to add a checkbox next to each domain - "Include subdomains". Or just a global checkbox.
Currently the way it's set up, it would require a redesign of how the extension stores and uses the whitelist.
Why? It's just a list of domains, there's no need in regex.
A separate regex whitelist input (turned off by default) gives the user the ability to do more complicated stuff at the risk of slowing down the clean up (the current algorithm for the whitelist is very fast). This also preserves the current whitelist which allows you to selectively choose which subdomains to include.
Also don't forget that you can just export/import the whitelist in a .txt file. So once you added all the domains/subdomains you need, you don't have to worry about redoing the whitelist again or on a new computer (like in SDC).
Export/Import is a really nice feature and I'm glad you included it (workaround for sorting: export, sort, remove all, import). RegExp is good, but they are a pain to code, why not simply support * and ? like the filesystem?
Still thinking about it. Though what I gathered so far, I might scrap the RegExp idea and do a check box for subdomain for every site on the whitelist UI table in settings. It would also make doing #20 easier since it would be another checkbox.
why not simply support * and ? like the filesystem?
Not sure how well that would work with the current implementation because the whitelist is set up using sets which it checks for a string match.
I haven't used SDC in a while so I'm pretty sure someone can chime in and answer it:
To my knowledge, SDC does not support this feature?
SDC modifies the built-in Firefox cookie WhiteList which does not appear to support wildcards, but it automatically includes sub-domains (see http://forums.mozillazine.org/viewtopic.php?f=38&t=2805917).
@B00ze64 From what I gathered, how it works is example.com will refer to *.example.com, while www.example.com refers to just example.com... that's given me another way to implement this. So here are some options and the difficulty of how it is to implement that have been discussed so far:
Others are free to give their opinion or other ideas.
If I look at my Firefox WhiteList, every single entry is http[s]://example.com, probably because I have been using AddOns (CookieSafe and now SDC) to manage that list, they all add the base domain. I like #3, but I come from Firefox, I am biased lol.
The standard way to handle subdomains in cookies is explained in RFC 6265 section 4.1.2.3:
For example, if the value of the Domain attribute is
example.com, the user agent will include the cookie in the Cookie header when making HTTP requests toexample.com,www.example.com, andwww.corp.example.com
So, I propose implementing subdomains as the only interpretation:
example.com allows cookies for example.com and *.example.coma.example.com allows cookies for a.example.com, *.a.example.com but not for example.com or b.example.comIf anyone is interested in beta testing it, Subdomain support is included in 1.3.0b3 under "Releases". I implemented it based on the interpretation of @alpernebbi , which is nice since there was no need for a whitelist redesign.
I've been testing 1.3.0b3 and 1.3.0b4 and they seem to work fine.
@m-i-k-e-y Thanks for the heads up. I released 1.3.0 now on the Chrome Web Store and AMO (subject to hopefully a not very long review). Once it's released on AMO, I'll close this.
Most helpful comment
The standard way to handle subdomains in cookies is explained in RFC 6265 section 4.1.2.3:
So, I propose implementing subdomains as the only interpretation:
example.comallows cookies forexample.comand*.example.coma.example.comallows cookies fora.example.com,*.a.example.combut not forexample.comorb.example.com