Reputation: 689
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
Upvotes: 26
Views: 88744
Reputation: 347
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()
);
Upvotes: 0
Reputation: 1488
Clearing the application storage from Chrome's DevTools fixed this issue for me.
Upvotes: -1
Reputation: 4568
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.
Upvotes: 0
Reputation: 119
I did a simple method. I went to phpMyAdmin then used a new password with MD5 hash. Then successfully logged in with that password
Upvotes: 0
Reputation: 11098
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.
Upvotes: 0
Reputation: 5202
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.
Upvotes: 0
Reputation: 575
Need to update 3 things in the core_config_data
table for following paths:
web/secure/base_url
web/unsecure/base_url
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.
Upvotes: 1
Reputation: 1397
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
Upvotes: 1
Reputation: 1551
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
Upvotes: 0
Reputation: 19
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
Upvotes: 2
Reputation: 3773
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.
Upvotes: 0
Reputation: 530
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.
Upvotes: 1
Reputation: 899
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
Upvotes: 1
Reputation: 63
Just clear cookies and cache in web browser. It works for me perfectly.
Upvotes: 6
Reputation: 1
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.
Upvotes: -2
Reputation: 253
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>
Upvotes: 1
Reputation: 151
I have also encountered this issue. This is what I did : In core_config_data, delete any rows where path = web/cookie/cookie_domain
Upvotes: 15
Reputation: 11
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.
Upvotes: 1
Reputation: 718
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()
);
Upvotes: 18
Reputation: 412
I have also encountered this issue. This is what I did :
In core_config_data
, delete any rows where path = web/cookie/cookie_domain
Upvotes: 2
Reputation: 2909
I solved just by cache clearing (execute php mage clear-cache from your Magento base directory
Upvotes: 1
Reputation: 689
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!
Upvotes: 40
Reputation: 6140
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.
Upvotes: 2