Two Sign-ins Required to Access store Admin

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

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

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

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?

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

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
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.

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

KenBaker:

... 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.

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

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?

mc123456789,

My first expectation (and still my strong suspicion) was exactly that, that my webhost (Host Gator) had made some change in the host servers that caused my ZC installations (login protocols, specifically) to suddenly act differently. Here's why: I have two ZC installations, both installed in subdomains. One is over a year old, and has been toodling along all this time. I created my Admin login shortcut when I carried out this first installation, lo those many moons ago. Using this shortcut, my logins always worked glitch-free (save when I really did mistype my username or password).

In January, I carried out a second ZC installation in a separate domain, and since then I've been actively working on this installation, including its various configuration files. As for my first installation, other than managing product maintenance, customer care, and orders, I haven't been making any other changes. As I understand the matter, and as I've seen from practical experience, ZC installations in separate domains have no complementary effects on one another, and they cause no adverse developments one to the other, because they're physically and operationally separate.

However, when this situation emerged about two weeks ago, it affected both of my installations, not just the second installation upon which I was making copious alterations. I would have immediately concluded that I had done something untoward if this glitch had affected only my second installation, but — as my first installation had been rolling along swimmingly for quite some time, yet it too suffered this glitch at exactly the same time — I assumed that Host Gator had made some server change that I needed to accommodate.

When I contacted the HG tech reps and asked what had changed, they responded: Ummm, nothing we know of. When I pressed a bit, they responded: Ummm, nothing we know of — must be how your code's parsing itself. When I pointed out that my code had been parsing itself just fine until quite recently, and that some change must have occurred, they responded: Ummm, nothing we know of.

Here's the thing: I got the glitch remedied, and I gained a Methuselah's lifetime of learning about php and server protocols generally, and the ZC program specifically, but I still don't know what caused the situation in the first place. To me, it's like solving a very difficult Sudoku through a lucky guess: You solved it, but not through rational enquiry. Most unsatisfying.

Anyway, thanks for the attention, and cheers,

Ken Baker

KenBaker:

mc123456789,

My first expectation (and still my strong suspicion) was exactly that, that my webhost (Host Gator) had made some change in the host servers that caused my ZC installations (login protocols, specifically) to suddenly act differently. Here's why: I have two ZC installations, both installed in subdomains. One is over a year old, and has been toodling along all this time. I created my Admin login shortcut when I carried out this first installation, lo those many moons ago. Using this shortcut, my logins always worked glitch-free (save when I really did mistype my username or password).

In January, I carried out a second ZC installation in a separate domain, and since then I've been actively working on this installation, including its various configuration files. As for my first installation, other than managing product maintenance, customer care, and orders, I haven't been making any other changes. As I understand the matter, and as I've seen from practical experience, ZC installations in separate domains have no complementary effects on one another, and they cause no adverse developments one to the other, because they're physically and operationally separate.

However, when this situation emerged about two weeks ago, it affected both of my installations, not just the second installation upon which I was making copious alterations. I would have immediately concluded that I had done something untoward if this glitch had affected only my second installation, but — as my first installation had been rolling along swimmingly for quite some time, yet it too suffered this glitch at exactly the same time — I assumed that Host Gator had made some server change that I needed to accommodate.

When I contacted the HG tech reps and asked what had changed, they responded: Ummm, nothing we know of. When I pressed a bit, they responded: Ummm, nothing we know of — must be how your code's parsing itself. When I pointed out that my code had been parsing itself just fine until quite recently, and that some change must have occurred, they responded: Ummm, nothing we know of.

Here's the thing: I got the glitch remedied, and I gained a Methuselah's lifetime of learning about php and server protocols generally, and the ZC program specifically, but I still don't know what caused the situation in the first place. To me, it's like solving a very difficult Sudoku through a lucky guess: You solved it, but not through rational enquiry. Most unsatisfying.

Anyway, thanks for the attention, and cheers,

Ken Baker

So, while a search of the forum regarding HG is likely to turn up some unfavourable comments, the above actually was some enjoyable reading. :) if nothing else can respect the dissatisfaction of fixing the problem. How contradictive is that?

Not sure what part of the world you are in, but regardless at least the current problem is fixed, right?

mc12345678:

Not sure what part of the world you are in, but regardless at least the current problem is fixed, right?

mc12345678,

Fixed, fine, and flying right along. Now I'm going to bed before the gremlins come in force to exact revenge.

Ken Baker

KenBaker:

mc12345678,

Fixed, fine, and flying right along. Now I'm going to bed before the gremlins come in force to exact revenge.

Ken Baker

Duck and cover always works, right? :)

Relax and carry a towel. :)

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. >

2. Begin login through [regular server]/catalog/suspense/login.php; assign zenAdminID.

3. While loading index.php, realize: Oops, we should be doing this login through the secure server.

4. 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
Hmm, interesting. While I've no clue as to the server-related changes that Host Gator made to effect the change in behavior, I can understand the process and it gives me additional food for thought. Thanks for reporting back with your findings.