While it is possible to install Magento locally, I cannot seem to get Magento to actually set cookies in the Admin when logging in if I use the hostname localhost:8080.

Having worked with Magento for some time, I am aware of this limitation and the local modification to Mage_Core_Model_Session_Abstract_Varien, to modify this check:

 if (isset($cookieParams['domain'])) {
    $cookieParams['domain'] = $cookie->getDomain();

To this:

 if (isset($cookieParams['domain']) && !in_array('', self::getValidatorData())) {
    $cookieParams['domain'] = $cookie->getDomain();

This works well for most local development environments. However, it does not work for Mac. I'm looking for an OSX-based solution.

I'm running PHP 5.4 webserver and this is for educational/experimentation only. In production I prefer Apache, under Linux. This would not be for production purposes - see my answer below for more details on how PHP interprets the local address for IPv6.

3 Answers 3


When starting your web server, you can either specify localhost or - the name you supply is not relevant, this isn't a virtual host declaration, it is just to specify the listening address.

But what you need to bear in mind is that your OS might resolve localhost to its IPv6 address, rather than its IPv4 address, so it will listen on the wrong protocol.

So be explicit and use when specifying the listen address.

But then for your store, just define a different host name as Alan suggested, that still points back to in your HOSTS file.

The PHP web server isn't listening for traffic destined to it for a specific server/hostname- its just listening for anything at all on that IP:Port - almost akin to a 000-default file on a clean Apache install.

So just ensure you install Magento with any hostname (other than localhost!), provided that it has a HOSTS entry pointing to

You need not ever edit any core files for this to work.


::1 !=

They both point to the same machine, but not the same protocol.


Over the years there's been numerous issues and regressions on OS X with webkit based browsers not setting cookies correctly for the localhost domain. If this is one of the problems you're running into there's not much you can do to fix it on the server side — it's a client-side problem. The localhost domain name ends up being treated differently that other domain names.

Not quite what you asked, but the best way to solve this problem is to not use localhost as a domain name, and instead use your /etc/hosts file to setup custom development domain names magento.dev, www.magento.dev, etc that point to

  • In the php 5.4 webserver I can't necessarily listen for anything besides localhost. localhost.dev or magento.dev return [Fri May 10 17:50:16 2013] Failed to listen on magento.dev:8080 (reason: php_network_getaddresses: getaddrinfo failed: nodename nor servname provided, or not known) - so I guess this issue may be local to that. I understand what you're saying and appreciate the constructive feedback. Perhaps the question should have prefaced my choice of dev server - and for experimentation.
    – philwinkle
    May 10, 2013 at 21:51
  • 1
    Phil, see my answer. You don't need to listen on a specific host name. You still listen on localhost/ - the listen address is for layer 4 only, not layer 7. It doesn't care about what host name you actually use in a web browser. May 10, 2013 at 22:13

On a Mac, change the Mage_Core_Model_Session_Abstract_Varien modification to the following:

 if (isset($cookieParams['domain']) && !in_array('::1', self::getValidatorData())) {
            $cookieParams['domain'] = $cookie->getDomain();

This works because ::1 is localhost on OSX, as revealed by an examination of the remote_addr as reported by self::getValidatorData():

array(4) {
  string(3) "::1"
  string(0) ""
  string(0) ""
  string(119) "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.65 Safari/537.31"


The address ::1 is the IPv6 equivalent of - it is a 128bit number, with the first 127 bits being '0' and the 128th bit being '1'. It's just a single address, so could also be written as ::1/128.

In the case of Apache (or another web server) being configured to use IPv6 addressing for the local

See this SO post for more information on coercing PHP to return an IP4 address instead - essentially configure your vhost to listen on the IP4 address - e.g. Listen


Other Sources: http://ipv6exchange.net/questions/16/what-is-the-loopback-127001-equivalent-ipv6-address


In my case, however, I am not using Apache and so the proposed solution was preferable and this answer is posted as a guide for others looking to set up local dev on OSX, specifically with PHP's built-in webserver. In addition, you should never commit this fix to any source control and it should not be used in a production environment

  • 2
    "localhost and are not recognized as the local loopback in OSX." Huh? What do you see at the top of your /etc/hosts file???
    – benmarks
    May 10, 2013 at 20:58
  • LOL @benmarks - you're absolutely right; so much for top-of-mind typing.... thanks for keeping me honest
    – philwinkle
    May 10, 2013 at 21:11
  • Well, if you are seeing ::1 in ::getValidatorData() then you have a point. I'm curious what the difference is, but DevOps already went home.
    – benmarks
    May 10, 2013 at 21:25
  • A quick search on the internets reveal that ::1 is the IPv6 equivalent of IPv4 address. ipv6exchange.net/questions/16/…
    – philwinkle
    May 10, 2013 at 21:41
  • @be marks localhost will resolve to either the IPv6 or IPv4 address, hence the ::1 . Some OS's define localhost as localhost6 to prevent legacy apps having problems like this. Ie. Using the wrong protocol May 10, 2013 at 22:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.