Two Sign-ins Required to Access store Admin

[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?

[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

[mc12345678]

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?

[lat9]

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

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.