Jump to content

Recommended Posts

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!

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

Posted (edited)

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:

Could contain: File, Page, Text, Computer Hardware, Electronics, Hardware, Monitor, Screen, Webpage

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

Could contain: Page, Text

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 by Michael Rubits
Link to comment
Share on other sites

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,
);

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...