When you migrate your Magento website from location to another, or you change the domain-name under which it is running, you might run into the problem that you can't login anymore to the Magento Admin Panel. Here are various solutions to this problem.

Localhost

One reason why the Magento login fails, might be that you're accessing the Magento website through the hostname localhost. Magento checks whether the hostname is a real domainname, and if it isn't, it fails to create the right cookies.

The only workaround is to fool Magento into thinking a real domainname is used. Under Linux or MacOS you could try using localhost.localdomain, but under Windows you will need to modify your hosts-file for this. Easier is just to use the IP-address 127.0.0.1 to access Magento.

If you are using a remote webserver, it's unlikely that this problem occurs.

Cookie domain

If you have moved your site, things might be cookie related. Make sure you cleanup your browsers cache and remove all Magento backend-cookies, to see if that helps.

Another reason why you fail to login, could be some setting within the Magento configuration. To alter this, you will need to open up the MySQL database - for instance by using phpMyAdmin. Navigate within your Magento database to the MySQL table core_config_data and look for a row with the field path set to the value web/cookie/cookie_domain. There might be multiple entries, but the one with the scope_id set to 0 should be matching the domainname you're using to access Magento.

If the database table core_config_data doesn't contain any row with path set to web/cookie/cookie_domain, don't add it because you don't need it. If you find multiple entries, be careful with what to change because you might break your Magento site completely.

If you use a database table prefix, the table core_config_data might actually be uii44_core_config_data or something alike. This makes it harder for hacker to attack your Magento site (SQL injection attacks).

Secure or unsecure URLs

Another problem could be that the so-called Secure URLs and/or Unsecure URLs do not match the current hostname. In this circumstance, Magento tries to redirect to the original hostname anyway. So watch the hostname in the browsers addressbar closely.

In the same MySQL table core_config_data you might find various entries with path starting with web/secure/base or web/unsecure/base. These also need to point to the right hostname. Note that the number of occurances could range from 0 (nothing configured) to 10 (everything configured).

Deleting and reconfiguring

Instead of trying to set the values above correctly, which could be a lot of work, you can also delete these entries and have a fresh start. You can use the following SQL-queries for this:

DELETE * FROM `core_config_data` WHERE `path` = "web/cookie/cookie_domain"
DELETE * FROM `core_config_data` WHERE `path` LIKE "web/secure/base%"
DELETE * FROM `core_config_data` WHERE `path` LIKE "web/unsecure/base%"

Check your file permissions

It's also worth taking a look at the permissions of your hosting environment. The folder var/cache within your Magento installation needs to be writable to the webserver, so new session-files can be created. If the folder is not writable, nobody is able to login.

Save sessions in the database

Instead of fixing the file permissions, you can also store the sessions in the database instead. You can accomplish this by editing the file app/etc/local.xml. Make sure you have a good backup of this file, and follow the exact syntax as below.

Locate the line starting with <session_save> and change the word files into db. So the following:

<session_save><![CDATA[files]]></session_save>

should become:

<session_save><![CDATA[db]]></session_save>

Save the file and sessions will be saved in the database instead. Please note that this change could have consequences regarding performance as well.