I never quite understood why using localhost as the host name did not work with Magento, for example when developing on your laptop Using 127.0.0.1 works, but localhost does not. For a while I thought it was some weird Magento restriction I did not understand, but the penny finally dropped when someone explained it (again) to me recently.
https://stackoverflow.com/questions/1134290/cookies-on-localhost-with-explicit-domain#16652347 has a good description. It is not Magento, it’s that web browsers behave differently when used with a domain name with less than 2 dots in it, such as localhost. The cookies are not saved.
So the easiest solution is either to use 127.0.0.1 or add a domain name to your local hosts file (/etc/hosts under Linux or C:\WINDOWS\System32\drivers\etc\hosts on Windows) with something like the following in it.
127.0.0.1 www.mydevbox.com
Using http://www.mydevbox.com as the domain name will then result in cookies behaving correctly. Mystery solved!
(I will leave deeper explanations to brighter minds than mine…)
Alan Kent's Blog 
Hm… For me it works with one dot: magento2.lh
“localhost” is special. When connection to MySQL it instructs the client to use the UNIX socket instead of TCP/IP.
“`
On Unix, MySQL programs treat the host name localhost specially, in a way that is likely different from what you expect compared to other network-based programs. For connections to localhost, MySQL programs attempt to connect to the local server by using a Unix socket file. This occurs even if a –port or -P option is given to specify a port number. To ensure that the client makes a TCP/IP connection to the local server, use –host or -h to specify a host name value of 127.0.0.1, or the IP address or name of the local server. You can also specify the connection protocol explicitly, even for localhost, by using the –protocol=TCP option.
“`
https://dev.mysql.com/doc/refman/5.6/en/connecting.html
Thanks for the comment. I should have been clearer that I was only referring to the use of “localhost” for the domain name in URLs, not for MySQL or other services. It is in a URL that causes a problem due to cookie management in the web browser.
Small correction/clarification — there’s no restriction in PHP on using cookies or (by extension) PHP sessions with the localhost domain. This small script (loaded in a browser) will work
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
gistfile1.php
hosted with ❤ by GitHub
The code at the above gist will remember the value set in the cookie and session, and successfully increment it on each page load.
The problem with using localhost and Magento stems from the core session handling code in `app/code/core/Mage/Core/Model/Session/Abstract/Varien.php`, and cookie handling code in `app/code/core/Mage/Core/Model/Cookie.php`. These files set an **explicit** domain for the cookie. That, combined with the undefined behavior for cookie domains that aren’t fully qualified domain names (https://www.ietf.org/rfc/rfc2109.txt) is what leads to a Magento site accessed via `localhost` not setting cookies (and again, by extension, session values).
If you look at the response headers for the script that works (https://gist.github.com/astorm/9f8297fe35171349f656), you’ll see something like this.
$ curl -I ‘http://localhost/test.php’
…
Set-Cookie: test=1
Set-Cookie: PHPSESSID=b7dhq11mfp98q85p1ic284cii7; path=/
…
That is, the cookies have no explicit domain set. Browsers seem able to cope with this.
However, try this with a Magento site, and you’ll see
$ curl -I ‘http://localhost:8080/’
Set-Cookie: frontend=inu7rsnitggt315mrrv5fl7lf5; expires=Mon, 27-Apr-2015 06:19:57 GMT; path=/; domain=localhost; HttpOnly
That is, a cookie an explicit domain set.
I mention this mainly because there’s a lot of “internet folk development” circulating that says you can “fix” numerous Magento session bugs by commenting out the session setting lines. Here’s one example of that
http://stackoverflow.com/questions/20623271/magento-login-fails/20625998#20625998
This, of course, leads to numerous other bits of unpredictable site behavior.
I can see how, from a certain point of view, it’s easy to say this is the browser’s fault, or PHP’s fault. That said, a case could be made that Magento 2 should make an effort in its cookie and session handling code to work through these ambiguities and provide an application that will work when accessed by a non fully qualified domain name (localhost, servername, etc.). The status quo leads users to comment out core parts of the Magento system and create other instabilities. Additionally, Magento 2 seems to be moving towards more vagrant oriented development, where there’s a culture of using localhost or non-fully-qualified server names to access your development VM.
Thanks Alan, I will see what we can do for Magento 2.
We use http://www.localhost.com and shove in etc/hosts. Then we forget about the issue, its just part of process.