phplist logs me off instantly

[Rufus125]

When I try to log in to the admin panel and click on anything, I am logged out automatically and receive the following error message:

"Your session was invalidated by a new session in a different browser"

When I log in again I see this error on the top of the page "Database error 1406 while doing query Data too long for column 'remote_ip4' at row 1"

Is phplist not yet IPv6 ready? Is there a workaround?

phpList version 3.6.15

[michield]

Ah, that's interesting. A workaround for now may be to remove the phplist_admin_login table in your database.

That will need some investigation to find out what's causing that.

[michield]

If you can add a line here:

https://github.com/phpList/phplist3/blob/main/public_html/lists/admin/index.php#L336

something like

print $remoteAddr; exit;

and then reload the page, can you post the output?

You may need to do a view-source if you get a blank page.

[Rufus125]

Hey @michield! The output is my public IPv6 address. 2a02:8388:xxxx:xxxx:xxxx:xxxx:xxxx:1f51

One thing I forgot to mention in my bug report: It worked with the previous version of phpList we used, which was 3.6.14 I think. I don't think the settings of my ISP changed in the meanwhile.

It works for my colleague who has a IPv4 public IP. It does not work for me with incognito mode enabled.

[michield]

Ok, are you only using IP6 to connect? I did add a column for IP6, but it's not in use at the moment. I guess we need to detect the IP4/6 and store it in the correct column and then use that instead.

One thing I forgot to mention in my bug report: It worked with the previous version of phpList we used, which was 3.6.14 I think. I don't think the settings of my ISP changed in the meanwhile.

Yes, this is new functionality. As common with web-apps, for security purposes it will now (a) detect a login from a new IP and (b) alert about it.

[phpListDockerBot]

This issue has been mentioned on phpList Discuss. There might be relevant details there:

https://discuss.phplist.org/t/your-session-was-invalidated-by-a-new-session-in-a-different-browser/9543/2

[torvista]

I have the same issue as getClientIP returns the ip6 address instead of the ip4 address.

[JLCarbwood]

We are experiencing the same issue. Is there any temporary solution for IP6?

[michield]

The temporary workaround was mentioned in https://github.com/phpList/phplist3/issues/1038#issuecomment-2089237698

It's a bit tricky to solve this, as I can't replicate it. But the way to resolve would be to "detect" IP4 vs 6 and store the data in the column that was already created for it. Happy to accept a PR for it.

[ebirt]

I recently had this error, and was able to fix it by going into the database to the phplist_admin_login table and increasing the size of the IP4 field to 50. For those who have deleted the table, here is the SQL to get it set back up, in a way that should work. I had this happen on two installations of phpList at a particular host, so I guess it has something to do with the PHP setup, and what kind of remote address is being detected. In any case, the SQL below will re-create the table. Make sure to run "Verify the DB structure" under the System menu, too. Hope this helps!

CREATE TABLE phplist_admin_login ( id int(11) NOT NULL, moment bigint(20) NOT NULL, adminid int(11) NOT NULL, remote_ip4 varchar(50) NOT NULL, remote_ip6 varchar(50) NOT NULL, sessionid varchar(50) NOT NULL, active tinyint(4) NOT NULL DEFAULT '0' ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

[torvista]

One aspect of this is the IP issue. Subsequently I found that the session was not being saved and consequently could not be restored.

As far as I can see PHPlist uses the default PHP handling/there is no cookie, but optionally can use a table: https://github.com/phpList/phplist3/blob/edbdc4f81b480f54be72c868337312f57abbb916/public_html/lists/config/config_extended.php#L778-L781 Enabling the line indicated, bypasses the session problem and restores functionality.

I found that the default php session save directory did not exist/was not writeable. You can stick this at the top of your admin/index.php for a moment if you want to check

    $session_dir = session_save_path();
    echo '$session_dir "' . $session_dir . '" exists? = ' . (is_dir($session_dir) ? 'true' : 'false') . '<br>';
    echo '$session_dir "' . $session_dir . '" is writeable? = ' . (is_writeable($session_dir) ? 'true' : 'false') . '<br>';
    die;

Where this value is being set is a hosting issue and of individual/academic interest.

Either the session path should be checked and set to a valid path accordingly, or this potential issue could be completely avoided by just saving the sessions in the database by default.

[phpListDockerBot]

This issue has been mentioned on phpList Discuss. There might be relevant details there:

https://discuss.phplist.org/t/phplist-suddenly-started-redirecting-me-to-the-login-form/71/19