Admin Login - Loop Of Death II

Thank you to whomever might be able to help.

I am a first-time installer. I'm looking for a simple shopping cart to replace the buttons I've been using that were provided by PayPal. I had hoped to install Zencart to evaluate it. I'm not having much luck.

I’m running (or trying to run) Zen Cart version 1.5.8a
The first problem: the https://www.dans.com/zencart/ page and the https://www.dans.com/zencart/zcadmin page both gave me a 500 error. I bumped php down from version 8.2.12 down to 8.0.30, and then they started working (or so I thought).

The admin page login doesn’t work. Like I found on "Royal Dave's" ticket, it’s in the “loop of death”. I attempt to login, and it appears as though the login page is just refreshing, and I’m prompted to log in again.

Royal Dave's similarly titled ticket that described what I had hoped was the same problem:
https://www.zen-cart.com/showthread.php?226057-Admin-Login-Loop-of-Death&highlight=admin+login+doesn%27t+work I followed along, and checked my php.ini, and I’ve got session.use_cookies set to 1. I must have a different issue.

Then I found this good article in the Zen cart documentation:
https://docs.zen-cart.com/user/troubleshooting/cant_login/

I made certain that I was using www. I temporarily re-named the htaccess file to something else, with no success. I cleared my browser cache and all cookies. I’m not seeing any errors in a server log (although as a newbie, I am not certain that I am in the correct log, or where that might even be). I’ve tried three different browsers.

I did find that I needed to update lines 17 and 22 of zencart/includes/configure.php and lines 16,32,33 and 38 of zencart/zcadmin/includes/configure.php to call out SSL, but these updates still didn’t fix the issue.

Side note, those configure.php files have lines that look like this:

define('HTTP_SERVER', 'http://dans.com');
define('HTTPS_SERVER', 'https://dans.com');

Maybe I need the www in them?

I went to phpMyAdmin and looked in the admin table. Admin is there, listed as a user, last_login_ip is blank, failed_logins os 0 and last_failed_ip is blank, so I don’t think there’s a problem there.

I’m grateful to anyone who can offer a suggestion.

Use https everywhere in both configure files. Yes, use www there too.

I’m not seeing any errors in a server log ...

Look in the folder "logs" (at the same level as "zcadmin"). There will be something there.

The file includes/configure.php (not the one in the admin folder) is at to read only and needs to be made writable before the explained changes can be saved.
Expected current permissions: 444, making 644 should make writable.

swguy:

Use https everywhere in both configure files. Yes, use www there too.

I’m not seeing any errors in a server log ...

Look in the folder "logs" (at the same level as "zcadmin"). There will be something there.

Thank you for your help, SWguy.

Now I have https, and www everywhere in both of those configure files.

I HAD found those log files, as I remember seeing them. Thank you for helping me to remember that detail. The most recent log entry however, is dated 11/10/23, the day that I installed Zen Cart on the server. There's nothing new there from the two login attempts that I just made (after I updated the configure files again). I don't really understand what the most recent log entry is telling us, though, so I'll share it here, in the hopes that it may make something clear to you.

[10-Nov-2023 23:06:41 America/New_York] PHP Fatal error: Uncaught IntlException: datefmt_create: invalid locale: U_ILLEGAL_ARGUMENT_ERROR in /var/www/vhosts/dans.com/httpdocs/zencart/includes/classes/zcDate.php:90
Stack trace:
#0 /var/www/vhosts/dans.com/httpdocs/zencart/includes/classes/zcDate.php(90): IntlDateFormatter->__construct()
#1 /var/www/vhosts/dans.com/httpdocs/zencart/includes/classes/zcDate.php(39): zcDate->initializeConversionArrays()
#2 /var/www/vhosts/dans.com/httpdocs/zencart/includes/autoload_func.php(47): zcDate->__construct()
#3 /var/www/vhosts/dans.com/httpdocs/zencart/includes/application_top.php(237): require('...')
#4 /var/www/vhosts/dans.com/httpdocs/zencart/index.php(25): require('...')
#5 {main}
thrown in /var/www/vhosts/dans.com/httpdocs/zencart/includes/classes/zcDate.php on line 90

[10-Nov-2023 23:06:41 America/New_York] Request URI: /zencart/, IP address: (my IP address...)
--> PHP Fatal error: Uncaught IntlException: datefmt_create: invalid locale: U_ILLEGAL_ARGUMENT_ERROR in /var/www/vhosts/dans.com/httpdocs/zencart/includes/classes/zcDate.php:90
Stack trace:
#0 /var/www/vhosts/dans.com/httpdocs/zencart/includes/classes/zcDate.php(90): IntlDateFormatter->__construct()
#1 /var/www/vhosts/dans.com/httpdocs/zencart/includes/classes/zcDate.php(39): zcDate->initializeConversionArrays()
#2 /var/www/vhosts/dans.com/httpdocs/zencart/includes/autoload_func.php(47): zcDate->__construct()
#3 /var/www/vhosts/dans.com/httpdocs/zencart/includes/application_top.php(237): require('...')
#4 /var/www/vhosts/dans.com/httpdocs/zencart/index.php(25): require('...')
#5 {main}
thrown in /var/www/vhosts/dans.com/httpdocs/zencart/includes/classes/zcDate.php on line 90.

Thank you mc12345678. I did update the file permissions so that I could upload the revised configure.php files, and then I restored them to 444. It would seem that was not part of the problem.

i would look here:

https://github.com/zencart/zencart/pull/6038

it is a known bug.

See this related/duplicate thread: https://www.zen-cart.com/showthread.php?229770-Site-Crashed-U_ILLEGAL_ARGUMENT_ERROR-in-IntlDateFormatter&p=1397704#post1397704

... or what @carlwhat said.

This is a good thought, Carlwhat - thank you for suggesting it. It brings something else to light. When I first installed Zen cart, I was running php 8.2.12. I got 500s on the zen cart pages. They went away when I bumped php down to 8.0.30. I just brought it back up to 8.2.12, and tried to hit the https://www.dans.com/zencart/ and the https://www.dans.com/zencart/zcadmin pages. I got the 500s again. Then I put php back to 8.0.30, and checked the log. I see a new entry for that invalid locale error that I don't understand again. So I think that's a php version issue - or something that needs to be fixed if I want to use 8.2.12 (and I do...). If I were to guess, I'd dare say this is a different problem, not the one causing the causing the loop of death.

lat9:

See this related/duplicate thread: https://www.zen-cart.com/showthread.php?229770-Site-Crashed-U_ILLEGAL_ARGUMENT_ERROR-in-IntlDateFormatter&p=1397704#post1397704

... or what @carlwhat said.

Could this be a different rabbit hole - the 500 error, and not the lopp of death problem?

It is a different problem but if you follow the advice provided, you will be in the clear.

Good morning.

Thank you for your continued attempts to help me. I think you're suggesting that I update the three files as outlined in this github post:
https://github.com/zencart/zencart/pull/6038/files

The third file is in the zc_install directory, which, if I'm not mistaken, is a directory that gets deleted after the install, so it is no longer there for me to update. I've updated the other two files just as the github files outline, but the problem persists. I still cannot login.

I tried clearing my browser cache, and I tried from another computer with a cleared browser cache.

I appreciate your time. Is there anything else that you can suggest, or should I throw in the towel at this point?

Please post the upper section of the site's /zcadmin/includes/configure.php, starting with the HTTP_SERVER definition and ending with the DIR_FS_CATALOG one.

lat9:

Please post the upper section of the site's /zcadmin/includes/configure.php, starting with the HTTP_SERVER definition and ending with the DIR_FS_CATALOG one.

Certainly. Thank you.

define('HTTP_SERVER', 'https://www.dans.com');
/**

• Note about HTTPS_SERVER:
• There is no longer an HTTPS_SERVER setting for the Admin. Instead, put your SSL URL in the HTTP_SERVER setting above.
  */

/**

• Note about DIR_WS_ADMIN
• The DIR_WS_ADMIN value is now auto-detected.
• In the rare case where it cannot be detected properly, you can add your own DIR_WS_ADMIN definition below.
  */

/**

• Enter the domain for your storefront URL.
• Enter a separate SSL URL in HTTPS_CATALOG_SERVER if your store supports SSL.
  */
  define('HTTP_CATALOG_SERVER', 'https://www.dans.com');
  define('HTTPS_CATALOG_SERVER', 'https://www.dans.com');

/**

• Do you use SSL for your customers login/checkout on the storefront? If so, enter 'true'. Else 'false'.
  */
  define('ENABLE_SSL_CATALOG', 'true');

/**

• These DIR_WS_xxxx values refer to the name of any subdirectory in which your store is located.
• These values get added to the HTTP_CATALOG_SERVER and HTTPS_CATALOG_SERVER values to form the complete URLs to your storefront.
• They should always start and end with a slash ... ie: '/' or '/foldername/'
  */
  define('DIR_WS_CATALOG', '/zencart/');
  define('DIR_WS_HTTPS_CATALOG', '/zencart/');

... and the DIR_FS_CATALOG setting?

lat9:

... and the DIR_FS_CATALOG setting?

oh, sorry, I didn't see that one:

define('DIR_FS_CATALOG', '/var/www/vhosts/dans.com/httpdocs/zencart/');

PM sent.

I had a nice telephone conversation with lat9. She is very knowledgeable, and helpful. Not too long into our investigation, we realized that the permissions on my zencart/zcadmin/includes/configure.php file were 444. I updated them to 644 and that appears to have solved the problem. I can now access the admin area. Lat9 is going planning some additional testing when time permits, to see if she can duplicate the issue and confirm this for us.

Meanwhile - thank you!

OrangeCrush:

I had a nice telephone conversation with lat9. She is very knowledgeable, and helpful. Not too long into our investigation, we realized that the permissions on my zencart/zcadmin/includes/configure.php file were 444. I updated them to 644 and that appears to have solved the problem. I can now access the admin area. Lat9 is going planning some additional testing when time permits, to see if she can duplicate the issue and confirm this for us.

Meanwhile - thank you!
... and I did that additional testing.:smile:

The admin's /includes/configure.php permissions-setting was not, in and of itself, the root-cause of the issue. My best guess is that the originally-suggested changes to that file were not applied, due to its read-only status. I now believe that my attempt to get a define('NOTIFIER_TRACE', 'true'); injected into that file exposed the file's read-only permissions and subsequently applied those initial settings which resulted in a successful admin login.