Cannot login to admin page after restoring from backup

[captainharlock]

Recently I attempted an upgrade which broke the front end, and I restored a copy I had made via tar.  After that the site was functional again except I could not login into the admin panel. 

This is the same silent failure mode that can be attributed to many different things which all add up to the same problem - when you login with the right credentials, you end up at the login page again without an error.   It is usually attributed to a cookie issue or a write permission issue in the session folder.    Because it happened after I restored from a backup, I at first thought it was a file permission issue, but I've exhausted my ideas there.  

Here's some of the things I have tried:

I compared the folder permissions for var/cache, var/session and var/tmp with another installation of magento I have on the same host provider.   I found that on the working copy, the permissions were set to 777, whereas on the broken copy, they were 755.    I changed the broken copy to 777, but it did not solve the problem.  If there are any other folders or files I should check, I'd like to know.

Next in app/etc/local.xml, I changed session_save to db rather than files, to bypass that problem entirely.   That also did not work.    Now looks like the following:

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

Since I could not log in to the admin interface, I manually changed "Use HTTP only" to "no" in session cookies management via PHPMyAdmin, as that was suggested as a temporary workaround.  That also did not work.

I ran magerun sys:check to make sure the cookie domain was correct.   No errors came up.

The secure and unsecure base URLs in core_config_data are correct and have not changed since it was working.

I have tried multiple browsers, clearing my cookies for that domain, logging in using a private tab, none of these things work.  

I am not trying to access it as localhost, which can sometimes be the problem.  this is a remote server with a properly configured domain name.

I'm about at wit's end.  This store is already set up and close to launch, so I can't simply start over.   One thing I could do is reinstall the software fresh as long as it can pick up the existing database so I can start right where I left off.   If there is a way to do that, perhaps that can be the next step.   But I also have to preserve any images and other user content that I have uploaded that exist as files in the app structure.

Any help appreciated.

[speerio]

Hello captainharlock,

What i don't read in your message is that you cleared the content of the var/cache and var/session folder.

Delete all the content in these 2 folders and try again.

[captainharlock]

---

@speerio wrote:

Hello captainharlock,

What i don't read in your message is that you cleared the content of the var/cache and var/session folder.

Delete all the content in these 2 folders and try again.

---

I did as requested and still same result.    The session folder still had nothing in it, the cache folder did.  Perhaps because I switched to db mode in local.xml?

[captainharlock]

This morning I decided to perform a fresh installation.  I found various pages that describe how to do that and preserve the old database.

I did so, and ended up at the exact same result.  Front end looks fine, can't log in to back end.   Same exact problem.

I am currently using db mode for sessions. 

A question about time zone settings that could affect cookies...should I set the time zone in Magento to whatever server is set to?   Or can I use my own time zone, which is different.  I have heard that incorrect time zone settings can result in session cookies that expire instantly, resulting in this problem.

[captainharlock]

---

A question about time zone settings that could affect cookies...should I set the time zone in Magento to whatever server is set to?   Or can I use my own time zone, which is different.  I have heard that incorrect time zone settings can result in session cookies that expire instantly, resulting in this problem.

---

Followup: I changed the time zone to the server time and it did not help.

[captainharlock]

I tried a thing just now where I cleared out the DB session data (since I am using the database option) and emptied out the physical cache and session folders, started in a new private window in Chrome and tried to log in.  No dice. 

[captainharlock]

Well, I'm about ready to pay someone to help me solve this problem.  I am at wit's end and no one else seems to have an answer either. 

[Ravindra Pratap]

@captainharlock

Have you tried the below one:

Go to app/code/core/Mage/Core/Model/Session/Abstract/Varien.php file within your magento directory.

Find the code:

session_set_cookie_params($this->getCookie()->getLifetime(),$this->getCookie()->getPath(),$this->getCookie()->getDomain(),$this->getCookie()->isSecure(),$this->getCookie()->getHttponly());

and replace with

session_set_cookie_params($this->getCookie()->getLifetime(),$this->getCookie()->getPath()//$this->getCookie()->getDomain(),//$this->getCookie()->isSecure(),//$this->getCookie()->getHttponly());

After this save the file. And try to login into the admin.

I think it will work now.

[captainharlock]

---

@Ravindra Pratap wrote:

@captainharlock

Have you tried the below one:

Go to app/code/core/Mage/Core/Model/Session/Abstract/Varien.php file within your magento directory.

---

I found that solution in a couple of places and was warned away from trying it as it is a hack / stop gap that is not a real solution and could cause other problems down the road.  However, I did try it now just to see if it would work since I've exhausted all other options so far, and it does not work for me.   Also, as a note, you would want to create a copy of the file in app/code/local/Mage etc. rather than modify the original file in the core directory.

The specific code you listed was not in my version of the file (I am using 1.9.3.6) but the code listed on this page was there:  https://magento.stackexchange.com/questions/26071/magento-1-9-can-t-login-to-admin-panel

In any case, it did not make a difference.   Still same problem...

Best,

-H

[captainharlock]

After some weeks of banging around on this, a solution has yet to be found, but a user here has generously walked through some settings with me in PM.   In addition to his help, I thought I would post this clue here to see if it rings a bell with anyone. 

To preface this, I have gone and matched settings with another, working store as closely as possible using PHPMyAdmin.   that store is being run on the same type of account at the same ISP.   having done that and cleared the cache manually, I logged into both while using Chrome's F12 debugging console to see what cookies were set under application -> cookies.

On the broken store, when you first go to the admin panel, it sets a cookie named adminhtml, for mydomain.com without a preceeding dot on mydomain.com.

When you then attempt to log in, it sets a second cookie also named adminhtml, with .mydomain.com (note preceeding dot)  then reloads the login page without error.  Both cookies remain.

In contrast, when I perform a successful login with the other store that is working, it sets only one cookie with the .domainname.com with the preceeding dot.    Stays that way after logging in.

I am wondering if there is a clue in there.   As if the broken site should not be setting the initial cookie for mydomain.com without the preceeding dot, and should be only doing .mydomain.com with the preceeding dot.      That's the only difference I can detect at this point.

if anyone might know a setting that might be amiss that would cause it to do that, I'd love to know.   Both stores are running on the domain root without a subdomain or www.  So https://mydomain.com/

-CH