Hello again.
Here is just a more detailed version of my initial assessment of the cause. Hopefully, it provides some usable information to the final solving of the LOGIN PROBLEM mystery.
I believe the problem is located in the following 'equation portion' of the 'if' statement:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # check session idle time
my $MaxSessionIdleTime = $Self->{ConfigObject}->Get('SessionMaxIdleTime');
if ( (time() - $MaxSessionIdleTime) >= $Data{UserLastRequest} ) {
$Kernel::System::AuthSession::CheckSessionID = 'Session has timed out. Please log in again.';
This routine is located in the following packages: Kernel::System::AuthSession::IPC; Kernel::System::AuthSession::FS; and Kernel::System::AuthSession::DB. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The 'TimeZone offset' is incorporated in the both 'index.pl' and 'customer.pl' as it defines the 'UserLastRequest' calculated value from 'Kernel::System::Time->System()'.
~~~~~
Since the offset is incorported in the 'UserLastRequest' with respect to the webserver's localtime on the right-hand side of the above equation, and is used in calculating the 'idle time' which is based on the webserver's time in the future, this offset must be incorporated in the time parameter on the left-hand side of the equation so that they'll use the same 'time basis.'
As the equation stands, the offset is NOT incorporated on the left-hand side. It only uses the 'raw time', "time()", not the 'corrected time', "time() + offset", as embedded in the equation below:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
time() - $MaxSessionIdleTime) >= $Data{UserLastRequest}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Therefore, in using the equation above as is, since the timezone offset for the United States, e.g. Eastern time zone, is negative (-4 hrs or -5 hrs; converting to seconds) relative to a webserver whose local time is set at GMT+0, it makes the right-hand side 'equal to' or 'less than' the left-hand side by the value of the offset BEFORE the time has had a chance to elapse when calculating 'idle time.' Then, since the 'SessionMaxIdleTime' is set at 4 hrs., the test of the 'if' statement renders 'TRUE' as soon as the login 'submit' button is clicked. My guess is that time has probably only elapsed some fraction of a second, NOT a whole 1-second to render the statement 'FALSE.'
In the strictest sense, as is, the equation is:
"time() -14400 >= [time() + elapsed seconds] + (-14400)",
whereby, the statement will always render 'TRUE' at login time when 'time()' on both sides of the equation are essentially equal since 'elapsed seconds' essentially equals '0'. This scenario for the Eastern timezone then becomes the point that represents an inflection point for the equation when the 'SessionMaxIdleTime' is set for 4 hrs (14400 sec).
From this, I would think the equation would work if the webserver time atthe start is on the same 'basis' as the time at the end, before the 'idle time' is calculated. This would then be for the scenario described above as:
"time() + offset -14400 >= [time() + elapsed seconds] + offset"
OR
"time() + offset - $MaxSessionIdleTime >= $Data{UserLastRequest}"AND with the numbers mentioned above at login plugged into the equation,
"time() -14400 -14400 >= [time() + elapsed second] + (-14400)", WHERE, elapsed seconds = '0' at login.
Then, the equation boils down to...
"-14400 >= 0", which renders 'FALSE' and allows SUCCESSFUL LOGIN!!!
Hope this helps in finding the final solution.
_______________________________________________ OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs Support oder Consulting für Ihr OTRS System? => http://www.otrs.de/
