Two Sign-ins Required to Access store Admin

[KenBaker]

An odd development:

I have two ZC installations, both functioning through subdomains on my main domain. For both installations, I use the same username but different passwords to access the Admin panels. About two weeks ago, I noticed that both ZC installations simultaneously started requiring me to enter my username and password twice before the systems will grant me access to my Admin panels. For both installations, after I type my username and password the first time and hit enter, the screen cycles a few seconds then returns to the login screen (no error message about wrong username or password). When I retype my username and password the second time and hit enter, the systems open my Admin panels.

I thought at first that the glitch must be originating with my hosting service (HostGator), but other password protected units of my domain don't show the same issue (they work as expected, in other words). I contacted HostGator anyway, and (after some checking) the tech rep assured me that the glitch isn't originating with the hosting service.

To the best of my knowledge, I haven't changed any basic configuration parameters that would have caused this glitch. Quite obviously, though, I've done *something* untoward to bring about this problem. I would appreciate any suggestions for identifying and correcting the cause of this login double entry. In and of itself, it's just a minor irritation, but I worry that it may be indicative of a more serious underlying problem.

Ken Baker

[lat9]

What are your settings in Configuration->Sessions for each of the subdomains?

[KenBaker]

lat9,

Thanks for your attention. I've never (ashamed to say) even looked at the Configuration > Sessions module. The settings for both domains are identical (save the Session Directory, of course), as follows:

Session Directory: [path from home to]/catalog/cache
Cookie Domain: True
Force Cookie Use: False
Check SSL Session ID: False
Check User Agent: False
Check IP Address: False
Prevent Spider Sessions: True
Recreate Session: True
IP to Host Conversion Status: True
Use root path for cookie path: False
Add period prefix to cookie domain: True

In my original post, I forgot to mention this bit of information, which may or may not be important: After I enter my login information twice to initially gain access to my Admin panels, I don't have to do so for subsequent logins after getting 15-minute boots from the server. That is, if I get disconnected from my Admin panels after 15 minutes of server inactivity, I only need enter my login information once to reconnect to the Admin panels.

Thanks again for looking at this issue.

Ken Baker

[lat9]

Using Firefox, go to each of your subdomains, click on the little symbol next to your site's URL, click "More Information" and you'll get to a menu where you can click another button to view the cookies associated with that site. Are the cookies for both subdomains the same?

[KenBaker]

lat9,

These little imbroglios certainly do lead to interesting knowledge. I wasn't sure if you meant for me to collect the cookie information for my site as viewed by visitors or for my Admin panels, so I checked both sets. In both cases:

• the session cookies are different;
• the cookies expire at the end of the session; and
• the site visitor cookies are labeled "zenID" and the Admin panel cookies are labeled "zenAdminID".

Ken Baker

[lat9]

lat9,

These little imbroglios certainly do lead to interesting knowledge. I wasn't sure if you meant for me to collect the cookie information for my site as viewed by visitors or for my Admin panels, so I checked both sets. In both cases:

• the session cookies are different;
• the cookies expire at the end of the session; and
• the site visitor cookies are labeled "zenID" and the Admin panel cookies are labeled "zenAdminID".

Ken Baker

As you can probably tell with the additional questions, I'm no closer to an answer ... but

The cookie in question for each site is the zenAdminID one. I'm guessing that since the cookies' values are different that the Path shown for each cookie is also different while the Cookie Domain is the same. Please verify.

Re-reading your original post, I can say that I normally use Firefox and have seen (although I can't pin down the symptom) the occasional case where I enter the correct admin ID/password and have it rejected as you indicated (no message), only to have the exact-same values accepted on the next try. For these cases I, too, have the same admin ID but different passwords and attempting to log into more than one admin console, but I don't think that that has anything to do with the issue.

Although I have not gone down into the code to verify, I believe that the double-entry has something to do with a previous session timeout, i.e. you were previously logged into the admin console so there is a valid cookie that has timed-out when you attempt login pass 1. I'm thinking that pass 1 of the login process sees the zenAdminID cookie and attempts to use it, finds out that it's timed out, regenerates the cookie and redisplays the login display. That's what allows pass 2 to complete successfully.

What version of PHP is being run on those subdomains? I've got PHP 5.4.8 running locally and 5.4.26 on my personal hosted sites.

[KenBaker]

lat9,

Please pardon the delay in responding. I've been wrestling with this issue since your last response, and have yet to find a solution. I do have some additional information that may bear on the issue, but first to answer your last questions:

About the cookies: Yes, the domain is the same for both cookies but the paths differ. The paths for both begin (of course) with my domain, but the path for the first assigned cookie ends with /catalog/suspense/login.php?xxx, while the path for the second assigned cookie ends with /catalog/suspense/index.php?xxx (the two cookie IDs appearing just after the ?, of course, in place of the xes).

About my php version: I'm presently running 5.3.28, but I can up that to 5.5.xx if need be via my htaccess. I haven't done so, as I suppose I should resolve this issue first. At any rate, I've been running the same php version since I first installed ZC, so I can't imagine that the version would have any bearing on this recent problem.

Here's what I've discovered over the past week or so. When I first try to login, the server goes through these steps (from the login screen):

1. Method POST: .../catalog/suspense/login.php?xxx (assigns first zenAdminID cookie)
2. Method GET: .../catalog/suspense/index.php?xxx (assigns second zenAdminID cookie)
3. Method GET: .../catalog/suspense/login.php?camefrom=index.php (cycles back to login screen, no error message)

In summary, during my first login attempt, the system *appears* to accept the login data and assigns a cookie (step 1), fetches the index.php page but assigns a second cookie (step 2), then for some reason cycles from the index.php page back to the blank login page.

Now, here's the key difference that occurs during my second login attempt (which must immediately follow my first attempt; even a delay of minutes will break the process): Step 1 occurs exactly the same; step 2, though, uses the *same cookie ID from step 1*; step 3 doesn't occur, because the system instead successfully opens my admin panel.

So I think that you're correct in surmising that the assignment of two different cookies causes the problem in my first login attempts. I don't, though, think that the problem occurs because of a stored, expired cookie. Here's why. Several times I've gone through the dual login process, and I've noted the cookie IDs used throughout. The system *never* reuses a cookie ID generated in a previous session: The cookies are always freshly generated and unique, no matter what stage of the process might be occurring.

This is all very deeply interesting to me, but I still don't have the least danged idea how to fix the problem.

Ken Baker

[lat9]

... This is all very deeply interesting to me, but I still don't have the least danged idea how to fix the problem.

Likewise; this session-related stuff makes my head spin! I'll keep looking for clues as well.

[KenBaker]

lat9,

I've resolved this problem finally, but not to my satisfaction, and not in a way that will likely have any value to you. Here's the situation in synopsis:

• From the time that I first installed ZC, I've had my Admin protected through my secure server.
  
• When logging into my Admin panel, I've been using this address: [domain]/catalog/suspense/login.php. That worked fine up until about two weeks ago.
  
• *For some reason* (me, I suppose, though I don't know what I could have done), my login protocol began to go through this process:

1. Begin login through [regular server]/catalog/suspense/login.php; assign zenAdminID.
2. While loading index.php, realize: Oops, we should be doing this login through the secure server.
3. Cycle back to the login screen, but this go-round through [secure server]/catalog/suspense/login.php; assign new zenAdminId; open Admin panel.

Bottom line, I just changed my shortcuts to start the login process directly through my secure server from the get-go, hence I'm not forced to go through the login process twice. So, I know *rationally* that I must have done something to bring about this glitch, which only began about two weeks, but *irrationally* I'm suiting up to go gremlin hunting. I keep a detailed log of every last little tiny itsy bitsy change that I make anywhere in my ZC files, and I can't in the least find anything that I've done that could have caused this glitch. I would like nothing better than to toss a couple nice thick gremlin steaks on the grill this evening, but it's likely not going to happen.

At any rate, your thoughts on the doubled cookies set me on the right track to the answer. Thanks for the help.

Ken Baker

[mc12345678]

I doubt I'm much help on this issue myself. I've seen the same problem with my local server, but usually it seems to be as lat9 pointed out that I was previously logged in, but timed out, or that I was on the admin login screen for an extended time and then tried to login only to get the login screen again. So also somewhat different.

Anyways, the real reason for writing: is there possibly something the host modified that is not under your control and caused the "response" that you unfortunately have seen.

It may be that you don't know the answer, but perhaps someone else may?