Too many redirects: Page 2

Too many redirects

mirkt

Hello,

From time to time, we still encounter this issue..

Today's example: the browser receives Too many redirects..

select * from ost_session where user_ip = 'XXX.XXX.XXX.XXX';

I see two rows:

session_data on the second row = 2980 characters, of which the first 1528 = session_data on the first row..

At the same time, I see a completely different OSTSESSIONID in the browser...

It seems like this is somehow related to a scenario where /scp (and a ticket) is open in one tab, and in another tab a new ticket is being created from the user perspective..

I would appreciate any thoughts and help

ntozier

So if this were me... I would shut off the HTTP Passthru Authentication.
Log in and try to recreate the issue.
If you cannot then it might be the plugin.

(or alternatively you could shut off all plugins and try to replicate and add them back in one at a time.)

mirkt

Hello,

I was able to reproduce the issue – I opened a ticket in /scp and started to type text in it (just opening the ticket wasn’t enough), and then trying to open a new ticket in the same browser (another tab) from the user’s perspective via open.php — I got a “too many redirects” error.

Then I disabled the HTTP Passthru Authentication plugin.

The "too many redirects" error disappeared, I saw the login screen, BUT I was not able to log in!

After: truncate ost_session; I managed to login successfully

So it looks like HTTP Passthru Authentication plugin is causing too many redirects error, BUT only because it can not successfully authenticate user..

Any ideas?

mirkt

Hello,

I noticed that the OSTSESSID cookie is set to expire in 24 hours in the browser, even though my PHP gc_maxlifetime is set to the default: session.gc_maxlifetime = 1440 (seconds)

After reverting to the old value, the cookie expiration is set to 1440 seconds in browser:

https://github.com/osTicket/osTicket/compare/v1.18.1...v1.18.2

I will give a try to older version of that line..

However, as far as I can see in the ost_session database table, the session_expire is still being set to 24 hours so there is some kind of mismatch between PHP session, OST session and browser..

In ost settings:
Agent Session Timeout = 0 (disable?)
User Session Timeout = 10 (minutes)

Any suggestions for tuning:
session.gc_maxlifetime
Agent Session Timeout
User Session Timeout

Regards
mirkt

KevinTheJedi

mirkt

Yea I’ve been recommending reverting that patch recently. We will be reworking that one soon.

Cheers.

« Previous Page