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 #1038 (comment)

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:

phplist3/public_html/lists/config/config_extended.php

Lines 778 to 781 in edbdc4f

	// you can store sessions in the database instead of the default place by assigning
	// a tablename to this value. The table will be created and will not use any prefixes
	// this only works when using mysql and only for administrator sessions
	// $SessionTableName = "phplistsessions";

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

[maltfield]

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.

Wow, this has been bothering me for years and it's what I was afraid of.

This is actually bad practice. Security-conscious users intentionally mask and cycle their IP address and other identifying properties to thwart fingerprinting.

For example, I use Tor and/or a VPN. And I use a popular web browser extension Chameleon to change my user agent every minute. There's enough users that employ such protections in their web browser that it's not a good idea to log someone off just because you can't track them between every page refresh.

Web apps shouldn't expect to be able to fingerprint users because good users are actively thwarting such fingerprinting.

Is this anti-feature documented anywhere, including how we can disable it in our config.php?

[michield]

@maltfield I doubt that your situation is common. This feature is to ensure that a session is not hijacked, so I'm not going to take it out. But this is Open Source, you're free to take out the check on IP. Should be as simple as commenting out a line or two.

This issue is about IPv4 vs IPv6, and I do think it's valid to make it work on IPv6.

[maltfield]

It seems like, maybe, another workaround for this is to add this to your phpList config.php

define('CHECK_SESSIONIP', 0);

it appears to me that this is a common enough bug for many people, as it's mentioned in config_extended.php

phplist3/public_html/lists/config/config_extended.php

Lines 221 to 225 in edbdc4f

	// to increase security the session of a user is checked for the IP address
	// this needs to be the same for every request. This may not work with
	// network situations where you connect via multiple proxies, so you can
	// switch off the checking by setting this to 0
	define('CHECK_SESSIONIP', 1);

@michield can you please confirm if defining CHECK_SESSIONIP as 0 will prevent folks from being logged-out if their IP address changes or cannot be found in the phplist_admin_login table? I ask because, if so, I'm confused as to why this wasn't the suggestion?