Can't log in to Magento Admin

Question

I'm having troubles logging into Magento's admin panel on one of our staging sites (it works 100% on our webdev servers and was working just fine not too long ago on the staging server as well).

I've done some research, and most people suggest that it's got to do with running Magento on a localhost and browsers not saving cookies for domains with no dots in the domain name. The problem with that, however is that we're running it from http://staging.sitename... etc.

Another few things that were suggested are where someone changed the default name for accessing the admin in the config, but we haven't changed it.

Does anyone have any ideas that might help?

Thanks for taking the time to help me out!

Kind Regards,
Rémy

Answer 1

I managed to fix it! I found this solution here: http://blog.chapagain.com.np/magento-admin-login-problem/.

I wanted to know why that fixed it though and var_dumped the items I commented out and realized that the cookie domain was being set to just '/' and we have magento set up under '/shop/'. So I went to the configuration section (having managed to log in after commenting out the 3 lines mentioned in the article), changed the Cookie Domain and Cookie Path to be blank and saved. I then uncommented those lines and tried again and all's working well!

Answer 2

In new Magento Installation, do the following ->

Open the file

app/code/core/Mage/Core/Model/Session/Abstract/Varien.php.

and change the code at line 87 to this ->

    $cookieParams = array(
        'lifetime' => $cookie->getLifetime(),
        'path'     => $cookie->getPath(),
      //  'domain'   => $cookie->getConfigDomain(),
      //  'secure'   => $cookie->isSecure(),
      //  'httponly' => $cookie->getHttponly()
    );

Answer 3

I have also encountered this issue. This is what I did : In core_config_data, delete any rows where path = web/cookie/cookie_domain

Answer 4

Just clear cookies and cache in web browser. It works for me perfectly.

Answer 5

Having the specific error would help. A couple shots in the dark -

It's worth checking your rewrites. I've had issues moving from server to server where one of them doesn't have the rewrite setup correctly. if servername.com/index.php/admin works, but servername.com/admin doesn't, then you have a rewrite issue.

It could conceivably also be that the base_url is not configured for the right server. Did you change it when you moved the database over? See my answer at this post for details.

Answer 6

I have also encountered this issue. This is what I did : In core_config_data, delete any rows where path = web/cookie/cookie_domain

Answer 7

Hi I had the same problem and I solved it by deleting all files in /var/session . I think it's because too many session in Magento!

and for security, I changed 'Use HTTP only' to 'No' in 'Session Cookies Management' of the 'Web' settings after I can loggin again..

I found this solution on the internet:https://magento.stackexchange.com/questions/26071/magento-1-9-can-t-login-to-admin-panel

Answer 8

I solved just by cache clearing (execute php mage clear-cache from your Magento base directory

Answer 9

Our site was running fine for months, then today no one could log into admin, nor could our users log into their frontend accounts. We run on a linux server.

Solution: the /magento/var/session directory was full of sess_* session files, so many in fact that attempting to execute rm * failed. After a tedious whacking of session files piecemeal (rm sess_1*, rm sess_2*, . . . rm sess_a*, rm sess_b*, . . . rm sess_v*) all of a sudden I could log into Magento again. Actually, I was able to log in after whacking just a few batches.

Theory: when the session directory has too many files, Magento may not be able to create new session files in a timely fashion, or maybe not at all.

Answer 10

I can´t access to backend!

(Solution for me):

app/etc/local.xml line 55

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

replace

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

Answer 11

If you use sample data:

Change: app/etc/local.xml line 55

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

replace

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

Then: Clear browser cache

Answer 12

We had the same issue and it was due to the server hard drive running out of space. Magento couldn't create a new session and therefore wouldn't log us in. Freed up the space and the issue was solved.

Answer 13

I have found a new simple way to solve this issue. I have spent hours and at the end I have, maybe for desperation, this step: Request the Administration password.

So, go to the admin login page and click on the forgot password link.

Change the password, and now you can login again!

Regards

Answer 14

Need to update 3 things in the core_config_data table for following paths:

1. web/secure/base_url
2. web/unsecure/base_url
3. web/cookie/cookie_domain

use commands like

UPDATE 'core_config_data' SET 'value'="localhost.com" WHERE path="web/cookie/cookie_domain"

and do not forget to clear cache and browser cookies.

Answer 15

I have been to the bottom of page 2 of gogole search results to try and solve this problem. I did everything I could find that was suggested. My friend then suggested this command line tool n98-magerun. Running php n98-magerun.phar cache:flush solved it. I could then log in. There's loads of commands though, so if that doesn't work, maybe another will.

Answer 16

After applying so many solutions and answers, this one worked at last.

Comment the Line 108~

call_user_func_array(’session_set_cookie_params’, $cookieParams);

in file app/code/core/Mage/Core/Model/Session/Abstract/Varien.php

Answer 17

I had the same issue, and it was all with the localhost.

First i changed web/unsecure/base_url and web/secure/base_url. These both config values were having localhost and i replaced it by 127.0.0.1 . Still it was not working until i deleted all contents of two folders var/session/ and var/cache/.

Now it is working fine.

Answer 18

For what is is worth, check that your password field in admin_user is at least 100 characters.

If it is 40, changing the password will not work.

Answer 19

I did a simple method. I went to phpMyAdmin then used a new password with MD5 hash. Then successfully logged in with that password

Answer 20

In my case session folder was missing under var folder. I just created var/session folder and set permission to 777, cleared cache and done.

You should check sysytem.log for this.

Answer 21

go to Varien.php app\code\core\Mage\Core\Model\Session\Abstract\Varien.php cleanup the files of var folder and make the mentioned changes:

        //session cookie params
        $cookieParams = array(
            'lifetime' => $cookie->getLifetime(),
            'path'     => $cookie->getPath()
            // 'domain'   => $cookie->getConfigDomain(),
            // 'secure'   => $cookie->isSecure(),
            // 'httponly' => $cookie->getHttponly()
        );

Answer 22

Clearing the application storage from Chrome's DevTools fixed this issue for me.

Answer 23

After doing all of that, And leaving all aforementioned solutions in place, still none of that worked for me. I run Win 7 + XAMPP and Magento Community magento-1.7.0.2

I could see the front-end, but no go on the login to the admin panel at all. All attempts were met with Invalid Username or Password, So I started messing with the Model files to debug, and finally changed

\app\code\core\Mage\Admin\Model\User.php line 340

From this :

if ($sensitive && $this->getId() && Mage::helper('core')->validateHash($password, $this->getPassword())) {

To this :

if ($sensitive && $this->getId() || Mage::helper('core')->validateHash($password, $this->getPassword())) {

Since it's a dev box, it will remain optional to validate password hashes I suppose

NOTE: Do not do this on a live environment, passwords will pass every time regardless to whether they are correct or not as long as your username is correct.

Essentially this code does the following if(username = correct or password = correct){LOG IN} - This means if it passes the username it will log them in.