Alan Kent posted a great article recently on Magento 2 behavior similar to what you describe that linked to this Stack Overflow discussion, but the key concepts are relevant to 1.X as well since it's more generally about cookie implementation logic not specific to Magento's codebase.
In short, the fundamental implementation of cookie handling logic has some requirements included within it to check for the presence of certain attributes of a domain name:
I broadly agree with @Ralph Buchfelder, but here's some amplification
of this, by experiment when trying to replicate a system with several
subdomains (such as example.com, fr.example.com, de.example.com) on my
local machine (OS X / Apache / Chrome|Firefox).
I've edited /etc/hosts to point some imaginary subdomains at
127.0.0.1:
127.0.0.1 localexample.com
127.0.0.1 fr.localexample.com
127.0.0.1 de.localexample.com If I am working on fr.localexample.com and I leave the domain parameter out, the cookie is stored correctly
for fr.localexample.com, but is not visible in the other subdomains.
If I use a domain of ".localexample.com", the cookie is stored
correctly for fr.localexample.com, and is visible in other subdomains.
If I use a domain of "localexample.com", or when I was trying a domain
of just "localexample" or "localhost", the cookie was not getting
stored.
If I use a domain of "fr.localexample.com" or ".fr.localexample.com",
the cookie is stored correctly for fr.localexample.com and is
(correctly) invisible in other subdomains.
So the requirement that you need at least two dots in the domain
appears to be correct, even though I can't see why it should be.
Thus, the best way to configure your local development environment to make sure you see behavior similar to your live environments is to update your hosts file to map a domain, any domain, to your local system, as long as it has a format of
xxx.yyy.zzz <- includes two 'dots' in the domain name
We've adopted a process of adding something like the following for sites we develop to our hosts file to make sure we don't have to fight with this kind of problem:
127.0.0.1 dev.somesite.com
127.0.0.1 dev.someothersite.com
After doing this, the odd behavior you describe no longer happens in our dev environments and we can get back to coding :)
You may still need to perform one of these two approaches to troubleshoot this kind of issue to make sure you create the correct local host entry in your hosts file:
If you have a (your_database_system) client that can connect to the database you're using, open it and run the following query:
select * from core_config_data where path like '%base%url%';
On my mySQL system I can open up MySQL Workbench and see something like the following:
Since you can also login to your Magento Admin back-end, you can also try browsing to the following menu option:
System -> Configuration -> Web which should display the following page.
Expand the Unsecure and Secure accordions and you should look for the fields marked Unsecure : Base URL and Secure : Base URL :
Add what you see in the Unsecure : Base URL and Secure : Base URL fields along with the URL your browser is displaying when you access the back-end and front end in the comments and we can figure out what's happening and a way to restore your functionality:
Best Answer
Check the table 'core_config_data' and seach for paths '
web/secure/base_url' and 'web/unsecure/base_url'.They should point to your local site.