0

So, I wrote some software about 6 years ago, and am about to release version 2.0. Recently, people have been complaining that data from one customer has been transferred to another. The culprit- uses having multiple tabs open, but browsers sharing a single session. (I got an "oh, by the way, this has been happening for a while now... ")

Luckily, I was made aware before I launch 2.0. My solution is to create a random session_name at log-in time. Then this name is constantly posted or geted to other pages in the application. It works great. The drawback, is that someone can look at the source code and see something like <input type="hidden" name="session" value="LSDT2341335054" /> Not to mention that a generated report (using GET) will show "&session=LSDT2341335054" in the url.

This was a very quick fix and it works great, but I could not find anything better out there. I work by myself so don't have any type of devil's advocate. Other than being a little sloppy, are they any real risks to this method? Just because I can't see a problem with this, doesn't mean they don't exist.

Thanks, Dave

the Hampster
  • 876
  • 1
  • 14
  • 21
  • Reading your comment on @Jake's answer, it seems you have a very RESTless app that's using sessions for state, instead of just identifying the user. A properly structured app has no problems with several tabs, even using sessions. Can you give more info about the architecture and why data is messed up across several tabs? – deceze Feb 15 '11 at 04:26
  • The software stores data on therapy goals for participants with disabilities. If User1 logs in and works with Data on participant1, The Session stores the user's ID and participant 1's ID. Now if a second tabs is opened, and the user pulls up Participant 2's info, the Session now reflects the same user, but stores the new Participant ID. Now the User goes back to the first tab, and changes some information. What ends up happening is that the info is saved to the second participant and not the first. It sounds to you like I should not be storing the Participants ID in the session. – the Hampster Feb 15 '11 at 23:46
  • My solution works very well- generating a separate session for each tab, but it's a pain to constantly make sure the session_name() gets passed along. But then again, sending along the participant's ID instead would be just as tedious. – the Hampster Feb 15 '11 at 23:47

1 Answers1

0

Well, isn't this new system just an extra layer on top of the previous session system, and users will only be able to see their own session identifier?

Can't really see the issue, it seems perfectly safe here, reminds me of things used in facebook messaging etc.

As deceze said, you could use cookies and check the values match, or a similar method.

Jake Lee
  • 7,549
  • 8
  • 45
  • 86
  • It is an extra layer, but it is required as the servers won't otherwise know which tab was sending the request. I must admit to dismissing the cookie idea because sessions are just stored cookies. Also, how can each tab keep track of the separate cookies? If there are three tabs open, then each request will send three cookies with each request. (Along with the session cookies.) – the Hampster Feb 15 '11 at 04:23
  • Not sure I quite understand. If you set a cookie on one, it'll be available for all tabs for as long as you choose? – Jake Lee Feb 15 '11 at 07:56
  • But that's the problem. You can't set tab-specific cookies, or can you? If it were possible, then I'm sure the whole sessions/tabs problem would be nullified. I'm surprised the browsers haven't thought of this! – the Hampster Feb 15 '11 at 23:17