Session variables not set

I am having an issue regarding session variables. When a user logs into the admin area I get their first and last names from a user table and store them in two session variables ($_SESSION['memberlastname'] and $_SESSION['memberfirstname'].

To track certain transactions of the database I enter selected information into a transaction log that includes the above session variables. I have recently discovered that some of the entries do not have the session variables set and thus the log field is blank.

Further, I have discovered that some users will log into the admin area via two different tabs.

So, my questions is... Is it possible that the session variables on the second tab is not properly set somehow?

It's not possible to answer your question without additional information. Session variables do not just disappear*, so this is almost certainly an error in your code, rather than an error in PHP processing your code.

*Sessions do time-out though, so this might happen if users are trying to do some action after an hour or two when the session is no longer active and then the session would be empty. But you should have security in place that would ask them to log back in if no session is found! Make sure this isn't the case, but even if it is, I'd imagine that would be relatively rare and you seem to be describing a more frequent problem. Is that right?

Note that sessions can expire in as little as about 10-15 minutes, depending on your settings (both what their browser does with the cookie and how long your server will accept the session), but they can last up to a few hours maybe even a few days.

Assuming that you have a single session set up for the entire site (it's possible to have different sessions running on different sub-domains for example), there's no reason to expect that any session variables would be available only at one time or another. A session is all-or-none.

So I guess we'd need to see more of your code to figure this out, but that may require you first debugging it to find where the problem is (that is, which file).

djr33,

Thanks for your response. It has taken me some time to track down the true nature of the problem.

Seems as though one of the users likes to have several instances of Chrome running at one time, one of which is used to make the edits in the database, but others may also be logged into the admin area. Additionally, she like to keep all of the instances running for multiple hours at a time.

It looks like I need to add some code to authenticate the session.

Thanks for your assistance.

Ah, that makes sense. Typically a single browser only allows one session, but if there are multiple instances of the browser running as different programs, then they could all act independently. If I use Firefox and Safari (my two primary browsers) I can be logged in as two different individuals (for example, here on DD, if I had two accounts) and they would never overlap. A session is established with the session ID cookie, which is sent by the browser, so it wouldn't be shared by other browsers or others on the same network (eg, an internet cafe or wifi connection).

You could check whether two sessions exist for the same IP, but I don't know what you'd want to do about it-- you wouldn't want to disable multiple sessions from the same IP in the event of, for example, siblings sharing an internet connection (assuming this is a public website), and you wouldn't want to un-securely share the session with everyone from the IP because that could lead to giving the wrong access to, for example, some other person in an internet cafe.

The typical solution here would be to allow only one session per account at one time. You can't really do this just with sessions, because sessions are only available to each individual user. Instead, you'd need a database (often used to extend sessions anyway) so that you could cross-reference sessions with the same username-- if found, log the older one out. If someone tries to re-use an older session, display "Your account has been logged on more recently on another connection." or something like that.


In short, she is using the website the wrong way. But that wouldn't be obvious to everyone and it's somewhat complicated to explain. If you can't convince her to stop doing that, then I suggest blocking multiple sessions per user-- she'd eventually figure it out and only use one. Note that there is no problem at all with using a multiple tabs/windows with the same session, as long as they're part of the same browser instance.


Additionally, you might want to force the session to time-out after 15 minutes or 1 hour of inactivity. It would mean that some work might be lost (if someone goes to lunch without saving first), but it would encourage them to pay attention to how they're logged in to the website.

I think I have come to the conclusion that I'll just have to live with the problem.

The site is a county genealogical site in Texas (TXFannin.org). It's main purpose is to provide information about the county for those tracking their family history. Normal users are not required to log-in so that is no problem.

Those that log-in are the volunteers who provide the information that is entered into the database for the researchers to search. At present the site has over 54,600 internment records for those buried in the county. It is one of the main volunteers that is causing the issue. Given the work that she does it is "best not to bite the hand that feed you" type thing.

Again, thanks for your insight and assistance.

jdadwilson
www.txfannin.org

Actually, there's one other way to do this, now that I've thought about it a bit more. You can store all of the information in the database rather than using sessions-- you can still use your same login and session configuration, but save the values in a database table called "session info" with the username as the index (rather than session id). Then anyone logged in under that username will share all of that "session", not just one browser.

The only potential problem there is overlapping information-- one window is open with old info; you save a new window; you return to the old window and resave. But that would likely be rare.

It might take a bit to set it up, but it could solve this if you need it.

If it's (more or less) working, you may just want to leave it as-is. I know what you mean.

What about setting the info with a cookie? The only thing that I need is the username (first and last) so that it can be stored in a transaction log that tracks when one of the volunteers makes a change to a database record.

I tried the cookie approach but am always getting a false return on an isset check.

I set the cookie... setcookie('UserName', "Joe Smith", time() + (60*60*24)); I look in the cookie list and it has been set.

But when I check it... if ( isset($_COOKIE['UserName']) ) { true stuff } else { false stuff } it always goes to false.

I am running WAMP on my local system for testing. Would this be the cause?

If you don't think this is a good approach I can always go to the DB approach. I already have over 50 tables, what's one more ;>).

Once again, I think you for your assistance. It is ones like you that make it easier for us old guys. Can you spell FORTRAN? AUTOCODER? COBOL?

jdadwilson

If you're already using a database, I'd say use that-- it'll be more reliable and you have total control over it.
A cookie will be subject to the same browser issues.


But the username? Are they logged in on all accounts? It sounds like something else might be problematic here. I thought there was specific/changing information that should be sent between the various browsers/sessions. But if this is just the username, there's a simpler solution: force them to log in if they are not logged in. There's no real way around that.

It sounds like there might be a problem with your login/security system: they appear to be logged in but don't have a username? They should lose access to the website if they're logged out-- they're logged out if they don't have a username.

(If you're not 100% concerned with security, you could also check the IP and then see which user used that IP last and then guess. Won't work if there's a shared computer/network, though.)


No problem. I've heard of those things, but haven't used them. I did use 5 1/4" floppies way back when though... and Windows 3.1 (at the time they were outdated, I admit).

The more I think about it and how the problem arises, I think it might be that the session is expiring and I am not properly accounting for that. Gotta do some more reading on authenticating users.

Again thanks...

Yes, I am one of the old ones. In 1973, as a young Air Force Captain, I worked at one of the seven (I think) organizations that actively used the ARPANET. We've come a long way since then.

jdadwilson

Quote:

---

I think it might be that the session is expiring and I am not properly accounting for that.

---

From what you've said, I think that's true.

There are two kinds of security with logins:
1. A door-- once you get through the door, you can stay active.
2. A monitoring system every time the user does anything.

Usually (2) is the better option. (1) is fine if you have anonymous logins-- perhaps a paid-only part of your site with a shared password for everyone (eg, downloading paid software after they get a confirmation email with a code).

It's easy to just do (1), but it's better to do (2) and check every time the page loads to be sure they're still logged in. You can either display "not logged in" or redirect them to the login page.

The extent to which this matters, of course, is the extent to which your data must be secure. In this case, I think you can fix it and make things easier for yourself.



--
I'm taking an engineering course at the moment with a professor who was there through most of the development of modern computers (and within speech recognition was part of the main innovation over the last 40 years or so), so he always has fun stories about punch cards and so forth.

I added a check to authenticate the session at the beginning of each admin module. If not authenticated it forces a new log-in. This seems to have corrected the problem from what I can tell so far.

Punch cards... ah, the good ole days? Dropped program decks were lots of fun... Computers with no tape drives... IBM 1401 Autocoder. Yep, they were fun times!

Again thanks for your insight and assistance.

I think this thread can be closed.

jdadwilson

Glad to hear it works.

We typically don't close threads (maybe someone else has a question), but you can mark it as "Resolved", by editing your post (in "advanced" mode). But I'll do that for you this time.