Well, this sucks.
Just upgraded to 3.2.0. After install and database upgrade, PHPList loops back to the login screen with any click in the interface (try just looking at statistics, and you are back to the login screen).
Another person mentioned something about a “varnish cache”, but no details about what that s or the steps needed to disable it.
Check your folder permissions, where you have installed phplist.
Because to me it worked
Thanks. What permissions did you use on which directories? Given that I kept the old directories, I would have assumed the permissions had not changed.
How are you getting on? Sounds to me like you didn’t restore the config settings right
Still looping.
I did what the steps called for: saving the config file before uploading the new code, then copying the config file back into its original location (if I had not done that, I would not have completed the database upgrade).
Were there required changes to the conf? I did not see any such in the upgrade docs.
mmm, no, that sounds fine. @duncanc @michiel any idea what’s going on? Seem to have an unusually high number of login “loopers” in phpList 3.2.0 ( @michiel there are more on other threads)
@gunfacts When you are logged-out, is there a message such as due to inactivity or change of IP address?
To rule out the IP address changing try disabling IP address checking in your config.php file, change the 1 to 0
# 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);Thanks for the question.
The answer is no, very doubtful about sessions/IP. Working from home with a rather typical home network (simple LinkSys router) to a standard Comcast link. IP rarely changes, and certainly not second-by-second. Also, CHECK_SESSIONIP was already set to zero as an earlier test.
I’m going to bump this issue and ask for guidance on bug report escalation.
I have two major communications to my base and the media, and cannot send them in PHPList’s current condition.
Hi,
Your best bet is to pay for support from the phpList developers, there is a form here: https://phplist.com/installservice - just link to the post and explain the issue, giving the info as requested. They will fix it for you.
This is not an issue affecting everyone, so it’s something quite specific to you, and it doesn’t look like it’s easy to identify either, so it seems unlikely it’s going to be fixed though generalised processes like bug report.
Kind Regards
Anna
phpList
Thanks. But as a former systems programmer, I am loath to pay someone to install software. I either need to debug the issue, or revert to the previous version (database and files were backed up).
Given that:
We may have a product defect corner case. Hoping to help the maintainer in the debugging process, but need them to guide the process.
I have the save issue after installing 3.2.0
I also have this problem so it is not confined to one individual.
If you want to try to debug this problem, this is the code in file admin/index.php at line 323 that causes you to be logged-out with the message ‘Your session timed out, please log in again’.
@gunfacts in an earlier post, did you mean that there is no message displayed when you are logged-out?
if (!empty($_SESSION["adminloggedin"]) && !empty($_SESSION['session_age']) && $_SESSION['session_age'] > SESSION_TIMEOUT) {
$_SESSION["adminloggedin"] = "";
$_SESSION["logindetails"] = "";
$page = "login";
$msg = s('Your session timed out, please log in again');
}
As a start try displaying the related variables by adding these lines immediately before
var_dump($_SESSION['session_age']);
echo 'session timeout ', SESSION_TIMEOUT;
SESSION_TIMEOUT should be 1800, and $_SESSION['session_age' is usually the time since the previous page was requested.
You should also check the event log, table phplist_eventlog, using phpmyadmin or similar to see whether phplist has put anything there.
Thanks, perhaps I spoke out of turn, I didn’t realise it was several people.
Thanks for the assist.
No error message is displayed. I checked the code snippet you provided, and that block is the same on my install. So the error message is being skipped or displayed and overlaid.
The vardump code did not display anything on screen, but when I do a source view of the page contents I see “session timeout 1800”, which agrees with your statement above.
Now for the bad news. The most recent event log entry is 2015-09-17, before the upgrade.
Here is a screen grab video of what we are encountering:
Sorry, I should have pointed out that you would need to have viewed the page source. This is what you need to look for
session timeout 1800
You might have missed the session age. int(14) means 14s since the last page request.
But if there is no message displayed then it won’t be this condition that is being hit. The other one that I mentioned is to do with the IP address.
Line 230 should be
$remoteAddr = getClientIP();
Can you add another var_dump after that
var_dump($remoteAddr);
That too should appear immediately after the <title> element when you view source, and should be something like
string(13) "90.193.206.53"
I have tried a few times, but the video doesn’t seem to play.
Can you use a browser tool such as Firefox web console to see what is actually being sent back by phplist?
@duncanc, this looks very similar to what we were working on… ipv6 could be the culprit. I looked up @gunfacts hosting, and it’s ‘ipv6 ready’.
The ipv6 issue looks like it has been addressed in the upcoming release (next week). in the mean time, perhaps gunfacts could try this fix to see if that helps?
Also, to view the video (it’s an .mp4 file), you need a plugin to process it. My computer is setup to use quicktime. If you are using Firefox, you can look in the ‘Preferences’ ‘Applications’ and search for mp4, it will then show you what the default application is for .mp4 files
Sorry for the delay. Busy work week here.
I inserted both debug sections, and here is the dump around the title tag:
phpList :: phpList :: Statistics overview< /title>bool(false)
NULL
session timeout 1800<link rel=“icon” href="./images/phplist.ico" type=“image/x-icon”
It almost appears as if the client IP address is returned as null. Perhaps this is the IPv6 issue Dan speaks of? For giggles, here is the desktop ipconfig dump (running over stock wifo through a consumer Linksys router out to Comcast).
Microsoft Windows [Version 6.3.9600]
© 2013 Microsoft Corporation. All rights reserved.
C:\Users\guysm_000>ipconfig
Windows IP Configuration
Ethernet adapter Bluetooth Network Connection:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Wireless LAN adapter Local Area Connection* 2:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Ethernet adapter Ethernet:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . : hsd1.ca.comcast.net
Wireless LAN adapter Wi-Fi:
Connection-specific DNS Suffix . : hsd1.ca.comcast.net
IPv6 Address. . . . . . . . . . . : 2601:647:cb02:6d6d:5d58:e163:d8d3:5013
Temporary IPv6 Address. . . . . . : 2601:647:cb02:6d6d:8846:9ab5:29ef:279a
Link-local IPv6 Address . . . . . : fe80::5d58:e163:d8d3:5013%3
IPv4 Address. . . . . . . . . . . : 192.168.1.101
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : fe80::c256:27ff:fe77:f5fb%3
192.168.1.1Perhaps. See above. IPv6 via Comcast though IPv4 on this side of the router.
I did not see the bug tracker associated with fix #17848. Do my symptoms agree with the source of this bug?