User login issue.

Kenny_Duval

I have an odd issue on a new vanilla installation of 1.12.3.

I am using normal logins for the User interface and using the LDAP plugin for the Agent logins. Agent logins always work. They are never an issue. User logins however occasionally appear to fail but are never logged as a failure. You can enter the user credentials correctly and are taken back to the login screen upon hitting enter. If you enter invalid credentials you do indeed get told but the system that login failed. On the instances where correct credentials are used there is no indication that the login failed other than being taken back to the login screen and not the ticket list.

If I go to another machine and use the same credentials I just tried then 9 times out of 10 the login completes and I am greeted with a ticket list. Now once logged in if the user never clicks sign out they can close the browser and come back to our support page and are dropped right in to the ticket list for their account as if they had signed in. If they click the sign out button there is a good chance that the next login with the same credentials will appear to fail again although there is no indication of a failure in the system logs. The URL also rolls to the ticket.php page but the sign in page remains displayed.

The developer tools in Edge show me an error related to a /td html tag that has no td to complete it but I'm pretty sure that is unrelated.

Kenny_Duval

This is the error I get related to the closing /td tag in the developer console.

HTTP422: UNPROCESSABLE ENTITY - The request was well-formed but could not be processed due to semantic errors.
GET - http://support.conklin-intracom.com/tickets.php

Kenny_Duval

This problem existed in my 1.12.2 install as well. I have reverted back to 1.12.2 since moving to 1.12.3 did not impact the issue.

Kenny_Duval

More information any time I issue a service restart on Apache the logins work as expected until you sign out of the session.

KevinTheJedi

@Kenny_Duval

Have you checked the server logs, PHP logs, etc. to see if there is any kind of warnings, errors, etc.?

Have you checked the cookies/sessions in the browser and database and compared to see if there are any differences? Have you compared the cookies/sessions between a working machine and non-working machine?

Cheers.

Kenny_Duval

I never get an error in the Apache access log when it happens..

- [16/Oct/2019:16:35:44 -0400] "POST /login.php HTTP/1.1" 302 13 "http://support.conklin-intracom.com/tickets.php" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.132 Safari/537.36"
- [16/Oct/2019:16:35:44 -0400] "GET /tickets.php HTTP/1.1" 422 5285 "http://support.conklin-intracom.com/tickets.php" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.132 Safari/537.36"

It appears the logins doesn't actually fail as they GET for tickets.php is there after the login. I also don't get any indication of a failure in the Apache error logs.

Kenny_Duval

I'd have to have some guidance digging into cookies and the database.

Clearing the cache and cookies does not appear to be helpful at this time. The only thing certain to be helpful is restarting Apache.

Kenny_Duval

So far this is the only real problem I need to solve before I can put it into actual use.

Kenny_Duval

Clearly the system knows when the credentials get entered wrong...

Kenny_Duval

I also don't see any logging of a failed login in the system logs when I intentionally enter the wrong credentials. That may been purpose but seems odd that a failure isn't logged.

Kenny_Duval

I think I may have solved it. Changing session.auto_start = o to session.auto_start = 1 seems to make it work.

Kenny_Duval

I get a lot of noise in the logs now but the logins work.

[Wed Oct 16 19:30:07.528856 2019] [php7:warn] [pid 2815] [client .25:54330] PHP Warning: session_set_cookie_params(): Cannot change session cookie parameters when session is active in /var/www/html/support/include/class.ostsession.php on line 56, referer: http://support.conklin-intracom.com/login.php
[Wed Oct 16 19:30:07.528908 2019] [php7:warn] [pid 2815] [client :54330] PHP Warning: session_set_save_handler(): Cannot change save handler when session is active in /var/www/html/support/include/class.ostsession.php on line 81, referer: http://support.conklin-intracom.com/login.php
[Wed Oct 16 19:30:15.527553 2019] [php7:warn] [pid 2818] [client :54339] PHP Warning: ini_set(): A session is active. You cannot change the session module's ini settings at this time in /var/www/html/support/bootstrap.php on line 19
[Wed Oct 16 19:30:15.527667 2019] [php7:warn] [pid 2818] [client :54339] PHP Warning: session_cache_limiter(): Cannot change cache limiter when session is active in /var/www/html/support/bootstrap.php on line 21
[Wed Oct 16 19:30:15.537170 2019] [php7:warn] [pid 2818] [client :54339] PHP Warning: session_name(): Cannot change session name when session is active in /var/www/html/support/include/class.ostsession.php on line 34
[Wed Oct 16 19:30:15.537333 2019] [php7:warn] [pid 2818] [client :54339] PHP Warning: ini_set(): A session is active. You cannot change the session module's ini settings at this time in /var/www/html/support/include/class.ostsession.php on line 40
[Wed Oct 16 19:30:15.537955 2019] [php7:warn] [pid 2818] [client :54339] PHP Warning: session_set_cookie_params(): Cannot change session cookie parameters when session is active in /var/www/html/support/include/class.ostsession.php on line 56
[Wed Oct 16 19:30:15.537998 2019] [php7:warn] [pid 2818] [client :54339] PHP Warning: session_set_save_handler(): Cannot change save handler when session is active in /var/www/html/support/include/class.ostsession.php on line 81

Kenny_Duval

This had the unfortunate side effect of messing with the ticket queue display.

Kenny_Duval

This is a session handling problem. The problem only starts if the following happens.

Login with a user account. Sign out.
In the same browser login to SCP portion and then logout
Remain in that tab and remove the /scp/login.php to take us back to the sign in page.
Try to login with previous working credentials only to be returned to the login screen.

When I look in the Apache error log I am greeted with the following.
[Wed Oct 16 21:53:20.339828 2019] [php7:warn] [pid 3939] [client :56180] PHP Warning: session_destroy(): Session callback expects true/false return value in /var/www/html/support/scp/logout.php on line 30, referer: http://support.conklin-intracom.com/scp/index.php
[Wed Oct 16 21:53:20.339972 2019] [php7:warn] [pid 3939] [client :56180] PHP Warning: session_destroy(): Session object destruction failed in /var/www/html/support/scp/logout.php on line 30, referer: http://support.conklin-intracom.com/scp/index.php
[Wed Oct 16 21:56:55.201309 2019] [php7:warn] [pid 3939] [client :56229] PHP Warning: session_destroy(): Session callback expects true/false return value in /var/www/html/support/scp/logout.php on line 30, referer: http://support.conklin-intracom.com/scp/
[Wed Oct 16 21:56:55.201458 2019] [php7:warn] [pid 3939] [client :56229] PHP Warning: session_destroy(): Session object destruction failed in /var/www/html/support/scp/logout.php on line 30, referer: http://support.conklin-intracom.com/scp/

Restarting the web server clears the issue temporarily.

Kenny_Duval

Unless I force session start in php.ini session keys are not being created in /var/lib/php/session which do get created when I force it. When it is forced those session keys are not deleted upon sign out from the system.

According to php.ini the following are set .
session.save_handler = file
session.save_path = "/var/lib/php/session"

There are also settings in /etc/httpd/conf.d/php.conf

php_value session.save_handler "files"
php_value session.save_path "/var/lib/php/session"
php_value soap.wsdl_cache_dir "/var/lib/php/wsdlcache"

I have to assume these are overriding the parameters in /etc/php.ini

KevinTheJedi

@Kenny_Duval

I cannot replicate the same issue. I did exactly the following:

Login with a user account. Sign out.
In the same browser login to SCP portion and then logout
Remain in that tab and remove the /scp/login.php to take us back to the sign in page.
Try to login with previous working credentials only to be returned to the login screen.

Cheers.

Kenny_Duval

Kevin, I currently have our system set tp force the session start. I'll be happy to change it and create you a login so that you may see the behavior. This can't be a widespread issue or you'd have more chatter about it here in the forums.

KevinTheJedi

@Kenny_Duval

Have you tried using PHP 7.2 or 7.1 to see if it's a specific PHP issue? Maybe the build of PHP doesn't have everything you need, etc.

Cheers.

Kenny_Duval

I can give that a shot.