Magento – magento 1.9.2.3 admin login not working

I gave up on finding help online, so I took it upon myself to find the answer. I eventually made an edit that fixed everything also note, if you have magento installed in a subdirectory, make sure folders that contain the magento installation do not have an .htaccess of their own or else it will conflict with the .htaccess in your magento root

Here is my magento root .htaccess:

   DirectoryIndex index.php

<IfModule mod_php5.c>

    php_value memory_limit 256M
    php_value max_execution_time 18000

    php_flag magic_quotes_gpc off

    php_flag session.auto_start off

    php_flag suhosin.session.cryptua off

    php_flag zend.ze1_compatibility_mode Off

</IfModule>

<IfModule mod_security.c>

    SecFilterEngine Off
    SecFilterScanPOST Off
</IfModule>

<IfModule mod_deflate.c>

</IfModule>

<IfModule mod_ssl.c>

    SSLOptions StdEnvVars

</IfModule>

<IfModule mod_rewrite.c>

    Options +FollowSymLinks
    RewriteEngine on

    RewriteBase /

    RewriteRule ^api/rest api.php?type=rest [QSA,L]

    RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

    RewriteCond %{REQUEST_METHOD} ^TRAC[EK]
    RewriteRule .* - [L,R=405]

    RewriteCond %{REQUEST_URI} !^/(media|skin|js)/

    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{REQUEST_FILENAME} !-l

    RewriteRule .* index.php [L]

</IfModule>

    AddDefaultCharset Off

<IfModule mod_expires.c>

    ExpiresDefault "access plus 1 year"

</IfModule>

    Order allow,deny
    Allow from all

    <Files RELEASE_NOTES.txt>
        order allow,deny
        deny from all
    </Files>

RewriteRule ^index.php/(.*)$ [L] 

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:

1. 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:

2. 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: