Solving login loops

[Michael Rubits]

Hi!

We're working on moving a database backup to a new installation in prep for a server move/rebuild, and we are finding that while we can login to the AdminCP fine, trying to login to the forum itself sends the user back to the login page. Inspecting the requests, I see Set-Cookie in the response headers, and I'm seeing ips4_member_id, ips4_IPSSessionFront and such in the response headers, but they never seem to get placed into the browser's cookies going by Chromium DevTools, even though the domain in the cookies seem to be correctly set to localhost:8080

Because this is a database backup from a live site, we're assuming there's a setting that needs to be changed somewhere. The live site is https, but conf_global is set to a non-https location, http://localhost:8080. We switched the license to -TESTINSTALL just in case that was somehow being used to determine cookie domain. We have setup rewrite rules seemingly correctly, such that we can at least browse the forums while not logged in, and view threads. The site's cookies contain the admin panel session ID cookie correctly when logging into the AdminCP.

I'm not sure what else would prevent a cookie from being set, and we can obviously login to the live site correctly, so it feels like this would be an installation configuration issue, but we're just not sure how else to narrow down this issue.

Thank you!

[Randy Calvert]

After the move, did you rebuild your system cache from the ACP’s support area?

[Jim M]

Would do as Randy mentioned, there are a lot of URLs cached in the system that after a URL change need to be cleared.

If that does not resolve it, ensure that you have not set any constants related to cookies in your constants.php file. If the domain has been hard set there then it will need to be removed or changed.

 

[Michael Rubits]

I deleted the datafiles directly completely a couple of times, but no change. Settings -> Advanced Configuration -> Data Storage is confirming the same path that I cleared. I did notice a path in "Template disk cache path" that needed to be updated from the old environment, but no change.

constants.php is empty; this is a fresh install. We went through the installation, got the clean default forum once the install is successful, and then dropped the db backup in.

For reference, this is what I'm seeing in the request when logging in:

but after logging in, the only cookies that actually appear are IPSSessionFront and IPSSessionAdmin

This is reproducible for someone else, so I don't think this is something on my browser. I've also tried in Vivaldi, Chrome, Firefox, and Edge just to really make sure its not some privacy default or adblocker.

Edited June 6 by Michael Rubits

[Jim M]

Are you configured to use HTTPS in your conf_global.php and accessing over HTTP or vice versa?

[Michael Rubits]

conf_global.php and the browser URL are matching here, non-secure: http://localhost:8080:
This was generated by going through a fresh install, before restoring the database backup. The only value that sticks out to me as suspicious is board_start, I'm not sure what that would be used for internally.

<?php

$INFO = array (
  'sql_host' => 'base_db',
  'sql_database' => 'ips',
  'sql_user' => 'root',
  'sql_pass' => '(password)',
  'sql_port' => 3306,
  'sql_socket' => '',
  'sql_tbl_prefix' => '',
  'sql_utf8mb4' => true,
  'board_start' => 1705031800,
  'installed' => true,
  'base_url' => 'http://localhost:8080/',
  'guest_group' => 2,
  'member_group' => 3,
  'admin_group' => 4,
);

 

[Jim M]

Is there a reason why you did a new installation and then restored the database backup instead of just moving the whole installation? That may create conflicts.

[Michael Rubits]

No specific reason, we were starting from scratch and also upgrading to the latest version in a new environment, and it seemed like the easiest way to take it step by step: first ensure we could get it up and running in a container, and then try and get the site working on top of that. We were also jumping enough versions that a PHP upgrade was required (4.3.3) which could not easily be obtained on a modern distro without compiling from source.

Would the recommendation be to grab a copy of the installed www directory, unzip the new version on top, and go through the upgrade process?

[Jim M]

Yes, you would never want to use the installer unless you're starting fresh with no data from a previous installation 😉 .

You'd want to grab your entire community directory, move that to your new server, connect it to your database in the conf_global.php and then upload the newest version on top of that.