Women in Technology

Article:		The PHP Scalability Myth
Subject:		Hidden variables for session state?
Date:		2003-10-17 17:00:15
From:		anonymous2
Response to: Hidden variables for session state?
Correct me if I'm wrong, but you seem to be suggesting a stateless presentation tier. Thus the session state must be moved either forward to the client (i.e., browser) or backward to the middle tier or (as you suggest) database. Let's consider each of these strategies: If you're putting the state in the browser as hidden variables, you *MUST* incorporate some mechanism to allow your app to detect whether it has been tampered with. Otherwise you are effectively giving a malicious user write access to their own session. Since the presentation tier is stateless, it has no intrinsic way to know whether the user has manipulated the session in order to, for instance, gain access to someone else's accounts. Encryption of the hidden variables would foil this kind of tampering, but at a cost in CPU cycles. Note that this encryption would have to be done *over and above* the normal https encryption because the two are serving different purposes: https protects the data from third parties, while hidden variable encryption protects the session from tampering by your own user. If you're putting the session state in the database, this solves the security problem and provides absolute protection of the session even if the whole server farm goes down. For situations where absolute session preservation is mandatory, this is a reasonable solution. The costs, however, are enormous, because potentially each request/response cycle results in an additional database write. Response time increases because the user has to sit waiting on an additional write, while throughput declines due to the increased traffic to and from the database.

Showing messages 1 through 3 of 3.

• Hidden variables for session state?
  2003-10-17 17:40:49  anonymous2 [View]
  
  
  Yes, you're absolutely correct.... BEAUTIFULLY STATELESS! One must exploit the advantages of their preferred programming env. And, I must say you're correct about the DB thing too. Remember, however, being right doesn't mean that when an environment is exploited for it’s strongest attributes that it is weak. On the contrary, if we exploit an environment along it's strengths then we push said environment closer and closer to 100% efficiency.
  
  Insofar as "The costs, however, are enormous, because potentially each request/response cycle results in an additional database write."...Potentially you are right.... and potentially you are wrong. It all depends on one's ability to design. I think in the end the lesson here is that we, as technologists, should design for two things: 1) to fulfill the business rules related to our implementation requirement AND 2) to take as much advantage of the programming environment as possible. If we don't we're just another bad example of the Edsel.
  
• Hidden variables for session state?
  2004-01-11 09:58:45  anonymous2 [View]
  
  
  Remember, however, being right doesn't mean that when an environment is exploited for it’s strongest attributes that it is weak.

• Hidden variables for session state?
  2003-10-17 20:23:47  tarrant [View]
  
  
  If you're putting the session in the db, you just need to send a cookie containing the id to the browser. This id wouldn't need to be encrypted all the time; you could simply give the browser a large random session id at the beginning, and you would therefore protect your sessions from spoofing.
  
  Actually, I've usually had a userid and sessionid in separate cookies, with the sessionid being a random number. If someone tries to use their sessionid but someone else's userid, then there's a system alert and the session token isn't vaild.