Why werkzeug does not allow using localhost for cookie domain?

Question

I'm using Flask and when I try to use localhost as the cookie domain, werkzeug says:

ValueError: Setting 'domain' for a cookie on a server running localy (ex: localhost) is not supportted by complying browsers. You should have something like: '127.0.0.1 localhost dev.localhost' on your hosts file and then point your server to run on 'dev.localhost' and also set 'domain' for 'dev.localhost'

This kind of sucks that each developer has to set a domain in hosts file to get the project working. I can't understand why werkzeug is preventing this!

The questions are:

• Why werkzeug is doing this?
• What would happen if it was possible to use localhost as cookie domain?
• How can i ignore this error?

Careen

You could map some fake hostnames to /etc/hosts to 127.0.0.1 for use in development. – Palikar

Answer 1

The issue is not that Werkzeug is blocking the setting of domain-based cookies - rather the issue is that most browsers do not support domain-limited cookies scoped to localhost (or to any other single-word domain). Rather than leaving you to debug this issue on your own (why is my session not being respected) Werkzeug detects when you are using this setup and errors out right away.

The closest thing that I have found for a reason is the pseudo-spec:

domain=DOMAIN_NAME

When searching the cookie list for valid cookies, a comparison of the domain attributes of the cookie is made with the Internet domain name of the host from which the URL will be fetched. If there is a tail match, then the cookie will go through path matching to see if it should be sent. "Tail matching" means that domain attribute is matched against the tail of the fully qualified domain name of the host. A domain attribute of "acme.com" would match host names "anvil.acme.com" as well as "shipping.crate.acme.com".

Only hosts within the specified domain can set a cookie for a domain and domains must have at least two (2) or three (3) periods in them to prevent domains of the form: ".com", ".edu", and "va.us". [emphasis mine] Any domain that fails within one of the seven special top level domains listed below only require two periods. Any other domain requires at least three. The seven special top level domains are: "COM", "EDU", "NET", "ORG", "GOV", "MIL", and "INT".

If single-name domains were allowed a hacker could set a cookie for .com and then have that cookie transmitted by the browser to every .com domain the end user visited.

See also: http://daniel.haxx.se/blog/2011/04/28/the-cookie-rfc-6265/

Altimetry

That's correct. but what if want to use this for development? I have other projects with localhost cookies and my browser (chromium) totally understands it! I think werkzeug is too much strict on this. Is there any hack to ignore this error for development? – Careen

@Careen - Werkzeug supports being run on localhost just fine - the issue is when you use subdomains (e. g. setting SESSION_COOKIE_DOMAIN or SERVER_NAME so you can use subdomains). Since that is what not all browsers support, Werkzeug stops you (because most things would still work - hence the debugging hell). – Altimetry

Answer 2

As @Markus Unterwaditzer proposed, you can fake hostnames locally to get and set the cookies associated to the domain names.

For this, do sudo vim /etc/hosts:

127.0.0.1   localhost
127.0.0.1   fakesub.fakedomain.com
127.0.0.1   foo.bar.baz.anotherfakedomain.org

This way, you can use and set cookies for the domains and subdomains fakesub.fakedomain.com, fakedomain.com, foo.bar.baz.anotherfakedomain.org, bar.baz.anotherfakedomain.org, baz.anotherfakedomain.org and anotherfakedomain.org.

---

I use this solution every day to locally develop websites for my company using the authentication provided by my company production website through the cookies.

Flem