Saturday, July 24, 2010

How to Fix Admin Login Problem in Magento


The Problem

The problem will manifest itself as a redirect back to the login screen, even though you typed the right username and password. If this problem is affecting you, you will be redirected back and see no error message. This indicates you have the right credentials, but the Magento Admin is just not letting you in. You can verify it by typing the wrong username and password, you’ll see you get redirected back and it shows an error message.
The problem occurs because the Magento backend tries to set a cookie on your browser, and then for some reason when you next make a request, the cookie is gone(or was never there). This makes Magento think you have never logged in, and of course it redirects you to the login screen. So the real guts of it is the missing cookie, we need to find out why it’s missing.

If you are installing locally using something like http://localhost, YOU WILL RUN INTO THIS PROBLEM! There are a couple ways to fix this:

1) You can reference your admin page by using (this way it has periods in the host name) instead of localhost or
2) if you are on windows xp, add a host record in your hosts file by going to: C:\WINDOWS\system32\drivers\etc and have point to something like magento.localhost
3) modify the core Magento code (keep in mind you may have to re-apply the fix if you update the code Magento code) - go to: app/code/core/Mage/Core/Model/Session/Abstract and open up varien.php, and comment out lines 73 (comment out the comma at the end of the line) through 76 so that it looks like the following:
// set session cookie params
$this->getCookie()->getPath() //remove this after putting on server (leave the comma)   ,
4. Domain Name with no Dots
This is the most common solution, if you have set up Magento to run locally (on MAMP for example) then you may be accessing the Apache webserver using the localhost hostname. A security setting in browsers means that the cookie will not be set, though apparently in FF3 at least, this behavior is a bug?.
So simply stop using localhost, you can use your localhost interface (e.g. or To determine your localhost interface you can look at the contents of your hosts file:
# Look for the number to the left of localhost
cat /etc/hosts
or your interface configuration.
# Look for interface loX with the LOOPBACK flag (probably lo0)

Once you know which number to use, you can replace localhost with the number. If you have already installed Magento using localhost then it will keep writing out links to localhost, even after you have changed to using the IP address, you will need to change the base_url values in the core_config_data table, you can run a query like this to find the right config values to change:
SELECT * FROM core_config_data WHERE value LIKE "%localhost%";
This should identfy two config values that will need to update with a query like:
UPDATE core_config_data SET value="" WHERE path IN ('web/unsecure/base_url','web/secure/base_url') ;
After changing that value you should delete your var/cache contents, and then refresh the page. Now you should have Magento running on an IP address, not a hostname with no dots in it.

5. Cookie Domain not matching Server Domain
This caught me out when I was replicating a remote site on my local mac development environment. I thought it’d be worth adding this solution here, seeing as this post still seems to rank well for Magento install problems. I had changed the base URLs but had forgotten to check the core_config_data table for any other Magento configuration data that might have been interfering with cookies. The config path in question is: web/cookie/cookie_domain.
You can check the table with an SQL command like this – you should be on the look out for config values that have hard coded the old URL:
SELECT * FROM core_config_data WHERE value LIKE "";
 -- Be on the look out for something like this:
|       513 | DEFAULT |        0 | web/cookie/cookie_domain               |                                     |
And update it to an empty string (less secure) or the new actual domain (more secure) as shown below:
UPDATE core_config_data SET value = "" WHERE config_id = 513;
-- or
UPDATE core_config_data SET value = "" WHERE config_id = 513;

Hope you would have get it done by now :)

Written by

Arvind is a web developer, programmer and blogger. He has expertise in PHP, Magento, WordPress, jQuery, JavaScript, HTML5 and CSS3. He loves to develop good looking websites with strong backend.


  1. awsome article..
    its worked for me......
    thanks a lot..

  2. it's good ! thanks alot

  3. What is config_id = 513 , every other system has different value

  4. Absolutely right, therefore I have said that you need to find the config_id first and then update it.

  5. I found your blog when I was looking for a different sort of information but I was very happy and glad to read through your blog. The information available here is great.

  6. Great post! Thanks This really is just remarkable,i appreciate your blog site and bookmarked it.

  7. Thanks for sharing these useful information! Hope that you will continue doing nice article like this.

  8. The post is written in very a good manner and it contains much useful information for me and i am sharing with my frieds.

  9. Really appreciate this wonderful post that you have provided for us.Great site and a great topic as well i really get amazed to read this.

  10. Hi Arvind
    I have tried to run this sql and found something lyk..

    98 default 0 web/unsecure/base_url
    99 default 0 web/secure/base_url

    Have not found that same result as you mentioned..

    Please guide me..
    Thanks in advance...


We would love to hear from you...


© 2014 Web Speaks . All rights resevered. Designed by Templateism