2

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('127.0.0.1', 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

When starting your web server, you can either specify localhost or 127.0.0.1 - 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 127.0.0.1 when specifying the listen address.

But then for your store, just define a different host name as Alan suggested, that still points back to 127.0.0.1 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 127.0.0.1

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

NB.

::1 != 127.0.0.1

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

1

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 127.0.0.1.

  • 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 '13 at 21:51
  • 1
    Phil, see my answer. You don't need to listen on a specific host name. You still listen on localhost/127.0.0.1 - 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. – Ben Lessani - Sonassi May 10 '13 at 22:13
0

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) {
  ["remote_addr"]=>
  string(3) "::1"
  ["http_via"]=>
  string(0) ""
  ["http_x_forwarded_for"]=>
  string(0) ""
  ["http_user_agent"]=>
  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"
}

Edit:

The address ::1 is the IPv6 equivalent of 127.0.0.1 - 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 127.0.0.1:80:

https://stackoverflow.com/questions/3699454/should-ip-serverremote-addr-return-1-on-a-mamp-localhost

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

Disclaimer

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 127.0.0.1 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 '13 at 20:58
  • LOL @benmarks - you're absolutely right; so much for top-of-mind typing.... thanks for keeping me honest – philwinkle May 10 '13 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 '13 at 21:25
  • A quick search on the internets reveal that ::1 is the IPv6 equivalent of IPv4 127.0.0.1 address. ipv6exchange.net/questions/16/… – philwinkle May 10 '13 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 – Ben Lessani - Sonassi May 10 '13 at 22:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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