Hi,
hoping someone might be able to help us with this one as we're well & truly stumped...

we have a site that uses PHP to authenticate users against a database and allow access if the login details are correct. We then have a script on each page to make sure the user is still logged in correctly & the session is still valid as they access the individual pages. There is a 5 hour timeout set on the cookie/session.

But when our client is browsing the site she is regularly getting logged out and asked to log in again. & we only have that problem when the site is accessed by someone from the clients company on their network.

So clients' IT Dept same back with:

"The issue arises because we load balance connections to the internet.

So a user could be using one of our links to get into the site in the first place and then browse a few pages and then click on a link which will generate a new http session which may be sent out our other link. This new session will have a different source IP address than the original session (through which the user was authenticated) and I suspect this is what prompts the server to re-authenticate the user.

If secure access is required to the point where the source IP is validated with each session, then the site should use https, which will not be load balanced. If the site relies on cookies for security, then it should ignore the source IP address."

& we thought we had addressed the issue by implementing the following:

The secure cert is in place and the URL being used to access the site is https://www.somesite/com.
We have examined our authentication script and we are not relying on the IP to keep the session alive and the user logged into the site.

BUT the client is still being asked to re-login and i'm all out of ideas - any help or suggestions would be excellent as the project is now at a standstill and the frustration is building.

Thanks in advance
carrig

Ok this might be a really amateur response, but I had a similar problem with a client, and it was actually because of the location of different files (which is quite strange).

The problem was resolved when I located all of the PHP files in a single directory - and when the access URL was always the same to each file - for example - if the login page is http://mysite.com/admin/login.php, then the page it resolves to should be http://mysite.com/admin/index.php rather than http://www... etc

Apologies if that wasn't any help, but its what fixed my problem.

Usayd thanks for your suggestion & for taking the time, but in this case i don't think that will resolve the issue. We have to have the files in separate folders as there are SO many of them & the site is going to grow even larger as time passes. But I will still mention it to the team here in the morning.

Thanks again.

Are you certain that the cookies are actually being accepted by the client? Since you already checked that your auth script isn't checking the IP, the session cookie should suffice as you are expecting - unless the cookie is getting refused and the app is not noticing. Also, have you checked that the session is not getting destroyed in some piece of code that is bugged? Just a couple of thoughts.

Are you certain that the cookies are actually being accepted by the client? Since you already checked that your auth script isn't checking the IP, the session cookie should suffice as you are expecting - unless the cookie is getting refused and the app is not noticing. Also, have you checked that the session is not getting destroyed in some piece of code that is bugged? Just a couple of thoughts.

-----

Thanks Ezzaral,
It must be the case that the cookies are being stored successfully otherwise the users on the client's network wouldn't be able to browse the site at all. Whereas now they can log in, browse through the site and then after an undefined & unpredictable period of time they get asked to re-login. Also we have tested it on various different browsers from different locations and the app works perfectly - we're only having problems with users on the client's network :(

Thanks for taking the time Ezzaral.

This article has been dead for over six months. Start a new discussion instead.