This is not a PHP-only question, but since I’m working in PHP I think it’s a good place to start.
I have a web site Holiday Mull with a login for members. Successful login (identification of login name and password) sets a SESSION variable which is used in a conditional to redirect the member to the ‘Members’ Area’ to edit their entries. It works perfectly well except for one member who has a satellite broadband link.
I have established that her login name and password are being recognised, but the SESSION[‘loggedin’] variable isn’t being set. The SESSION is being started OK, I can echo its other contents to her screen before and after login attempts. Since this is all going on at the server, not at her computer, I don’t understand how the variable can fail to be set. UNLESS the server needs to refer to the PHPSESSID cookie before it writes anything new to the SESSION ? In which case perhaps the delay in the satellite link results in a timeout.
I’m grasping at straws here, does anyone have any suggestions, please ?
… not using ‘loggedin’?
You said you can see other data in her session. Why store a useless variable? You know she’s logged in, because that other data is there…
Thank you for your response.
Any visitor to the site will have a session running, it’s used to keep track of database searches etc. The public visit the site looking for accommodation etc. Only members can log in to change their records in the database. I echoed her session to the screen during the login process in order to convince myself that a session was being started (which it is), and that the ‘loggedin’ variable wasn’t being set. The session is started as soon as any visitor accesses the site, before there’s any further inter-action. The ‘loggedin’ variable only gets set when a member logs in.
I’ve even added a ‘mail’ command part way through the login process so that I get an e-mail when her password is verified. The e-mail duly arrives. The only thing that’s not happening exactly as on a normal broadband connection is the setting of the ‘loggedin’ session varaible. This member can log in perfectly well from another location, so the problem must be something to do with her satellite link, and the obvious difference is latency. I’m well aware that all this sounds like nonsense, but I can only tell it as it is. I do know this member, and can vouch for her ability to log in to a web site.
I’d gladly quote reams of code, but I’m not sure it would be helpful.
I have now established that OTHER Session variables set during the login process, at the same time as ‘loggedin’, are being recognised over the satellite link and I can echo them to the member’s screen (but I can’t echo ‘loggedin’).
Since I’m using ‘loggedin’ to test for successful login, it fails, of course. On normal broadband connections ‘loggedin’ is recognised (and echoed to screen) and login succeeds. Completely non-sensical ? I’d have to agree, but that is how it is appearing.
It can hardly be a typo, since it works in the vast majority of cases.
I could change the test and look for one of the Session variables that is being set, but at this point that would be a cop-out. I’d be no nearer finding out why this variable is not being recognised over the satellite link.
Only thing i can think of is to locate any place in the code where your system interacts with ‘loggedin’ and make sure there’s nothing that may be unsetting it in your code.
Thank you.
I keep looking for that. But there’s always the conundrum that it works perfectly well on a normal connection. There’s a check for ‘loggedin’ every time a page in the members’ area is opened, for obvious reasons. But nowhere have I found it being deliberately unset until the member quits.
I’ve started asking myself paranoid questions like could a satellite link have ‘loggedin’ as a reserved word ? I don’t know in detail how satellite links work, but they must have some way of avoiding interception/interference, which suggests extra layers of security.
Session variables never leave the server, so the type of connection would have no effect on it. 
It’s honestly a mystery to me, unless somehow the user in question is sending the logout signal… but if that were the case, i’m sure you destroy the entire session, so the rest of the data would be missing as well…
Have you tried a var_dump($_SESSION) instead of an echo? Maybe the loggedin is getting set to null somewhere…
No indeed. That was where I started too. But something is different because of the satellite link, and at some point you begin to question everything. If you don’t you can miss the obvious
It’s honestly a mystery to me, unless somehow the user in question is sending the logout signal… but if that were the case, i’m sure you destroy the entire session, so the rest of the data would be missing as well…
Yes. I’m satisfied she’s not that incompetent.
you tried a var_dump($_SESSION) instead of an echo? Maybe the loggedin is getting set to null somewhere…
In the presence of ‘loggedin’ she’d get to the Members’ Page, and only ‘loggedin’ would be echoed. In the absence of ‘loggedin’ the entire $_SESSION is getting dumped to her screen, but I’m doing it with:
$sess = session_encode();
echo $sess;
which I imagine has the same effect ? This is how I discovered that other variables were present (notably ‘loggedbus’ which gives her business name. Now if ‘loggedbus’ can make it, why can’t ‘loggedin’ ??!!
I think I’ve got enough information to go forward from here, and if renaming the variable works I guess I’ll have to be content with that.
Hello StarLion: I got to the bottom of this in the end, but there’s still something that puzzles me.
The site (holidaymull.co.uk) has a control script (/index.php), which does contain a conditional to delete $_SESSION[‘loggedin’]. The login process is contolled from another script ‘/members/index.php’. After successful login members are sent back to ‘/members/index.php’, but the way I did this was:
// REDIRECT SUCCESSFUL LOGIN:
header("Location: index.php");
exit(); // Quit the script.
This command was given from within a php file ‘/members/member_functions.php’ and it worked fine from most connections, returning to ‘members/index.php’ as required. However, the member on the satellite link was being sent back to the MAIN control script (/index.php), and therefore the ‘loggedin’ variable was being deleted. Why she (alone) was sent back to the main script is the remaining mystery, but it must surely be something to do with timing.
I’ve solved the problem with:
// REDIRECT SUCCESSFUL LOGIN:
header("Location: /members/index.php");
exit(); // Quit the script.
which works for everybody so far. The moral is that one must be as specific as possible with one’s coding.
Thank you for your help.