magento admin不能登陸 無提示（除火狐）

magento後臺登陸之後自動返回登陸見面 沒有任何提示（火狐能正常登陸）
查資料發現了N種可能性
數據庫中設置問題、域名問題
http://www.yireo.com/tutorials/magento/magento-administration/651-unable-to-login-into-the-magento-backend

Unable to login into the Magento backend
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
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.


http://stackoverflow.com/questions/2004357/magentocommerce-development-environment-domain-issue/2005096#2005096

I'm running Magento on a Production server and a number of development and test domains.

The domain isn't hardcoded in any file - the domain is all in the database.

You have to change the secure base url and the unsecure base url when you move from server to server. Both of these are stored in the database and can be changed in the web based administration screens. When moving the database from one host to another, I use a script that does little but update these values. Here's the SQL you need to update these values:

update core_config_data set value='http://whatever.com/' where path='web/unsecure/base_url'; update core_config_data set value='https://whatever.com/' where path='web/secure/base_url'; You may also want to pay attention to the local.xml file where the database connection is configured. I'm sure that you'll want to have the different instances using different databases. In my configuration, I leave this file out of source control, and configure it just once for each instance.

https://technologygurusinc.com/blog/?p=5
Can’t log in to Magento admin
Yesterday evening, after doing damage to brain trying to figure out how to override individual actions on Magento core controllers, I suddenly found myself unable to log in to my Magento admin.

It didn’t give me an ‘Invalid Password’ message and it seemed to post the form well enough (it was successfully generating a session key every time), but it always rerouted me back to the admin login screen. On every browser (except Firefox), the login process was equally ineffective.

I was mystified. I tried changing the controller back to the way it was, disabled all my custom modules, deleted all my cookies. Still nothing. I SSH’d into the server and checked for errors in the var/log directory, but found nothing. I manually cleared the Magento cache by deleting everything from the var/cache and var/session directories. I ran a tail on the access.log file in our home directory, and on the Apache2 server installation, scouring for PHP errors. Nothing.

We finally figured out what was happening. When you submit the admin login form, the IndexController in app/code/core/Mage/Adminhtml/controllers calls the isLoggedIn() method on the admin session scope. It can’t find your session, so it assumes the session is timed out and redirects you to the login screen.

This means that the session is not being instantiated properly. Except in Firefox. In every browser but Firefox, if the server time doesn’t match the client time, the browser will often fail to instantiate cookies properly. So we SSH’d into the server and checked the date and time.

Sure enough, a reboot had reset our server’s time. Our server thinks that is 10:52, whereas the client knows the truth–it is actually 11:56. So we use the command line to change to the correct time:

sudo ntpdate stdtime.gov.hk

sudo hwclock -w

sudo dpkg-reconfigure tzdata

And then I try to log in once more, and it’s fixed! I can log in again. And I only wasted about three or four hours. Awesome. Now back to work.

If you are unable to log into Magento’s admin, try doing this. I can’t guarantee it will work for you, since any Magento problem could potentially be traced to a number of different root causes. But it’s worth a shot.


我的解決方法一直試到最後才行
系統時間導致……還真讓人費解