Women in Technology

Hear us Roar



Article:
  The PHP Scalability Myth
Subject:   Hidden variables for session state?
Date:   2003-10-17 11:39:41
From:   anonymous2
"Transient user interface information is stored in hidden variables on the web page."


Are you out of your mind? In "J2EE Core Patterns" they mention this architecture in passing as an example of how *not* to do it. It's insecure because a user can put any damn thing they want in those hidden variables. There are also bandwidth issues unless you keep that state very, very small, which is possible for simple Web apps but not for highly interactive sites.


If you require the ability to failover the presentation tier without losing active sessions, Weblogic supports HTTP session state replication via RMI: if the servlet changes the session, Weblogic will use RMI to send the change to the standby server, so that if one node in your presentation tier fails another can take its place starting with the session state just as the original node left it. The user doesn't need to know anything has happened.

Full Threads Newest First

Showing messages 1 through 10 of 10.

  • Hidden variables for session state?
    2003-10-17 12:09:23  anonymous2 [View]

    My dear person..... To keep the user from inserting "anyting" they want one only needs to restrict hidden fields to a know set of responses AND restrict their use to the $_POST['<variable_name>'] usage type. These two things coupled make for a situation that is quite annoying to those who would "put anything they want" in the hidden field value. Have a nice day.
    • Hidden variables for session state?
      2003-10-17 12:32:11  anonymous2 [View]

      How about a known set of responses for, say, a price? Any non-combo-box sort of data? A credit card? There's plenty of data where it's not so easy to know what's valid and what's not. Just because there are say, four known responses, it doesn't mean that any of the four are really appropriate for the current user. As far as POST vs. GET...I can submit anything I want (with any claimed User-Agent) that I want via POST with HTTPUnit.

      Not to mention the overhead of taking a complex set of data, serializing it to something that is acceptable to HTTP forms, and then deserializing it back to object-land when the request is submitted. If you're a simple online store, sure, PHP and the bad patterns you suggest will suffice. Write a very complicated enterprise app that has to support tens of thousands of concurrent users with failover with PHP and then come back. You can unplug the LAN cable from a server mid-request and WebLogic will fail over without a hitch. Stick that in your crack pipe and smoke it.
      • Hidden variables for session state?
        2003-10-17 15:17:31  anonymous2 [View]

        The problem with your position (IMHO) is I've already done the things you suggest...hundreds of thousands of lines of code....maintained by disparate developers on different continents, some of whom DO NOT speak the same language....using OO to provide classes, methods, etc.....blah, blah, blah....using both coding environments (Java and PHP).

        The unplugging the cable thing is easily solved by using a DB to store one's session info and *NOT* a memory resident process to keep track of uniquely identified users. You see, in the world of system design simplest wins and most complex looses. Store info in EJBs in memory....sure, why not...of course if the WebLogic/JBoss/other Java engine hiccups or because of latency fails to replicate session(s) to peers....viola, lost sessions and pissed users. In the DB scenario the session persists happily and the user never knows if ONE OR MORE of the cluster members went down because there's NO NEED FOR SAID USER TO CARE. On the issue of WebLogic failing over without a hitch, not so fast. I've seen it fail to do just that MANY times from Ver 6.x through current releases.

        On the "bad patters I suggest"....I wasn't suggesting anything. I was simply mentioning how one might reduce the complexity of their design by thinking in simple terms. Again, simple wins, complex looses. Item prices for goods and services should ALWAYS be know to the selling business unit that's selling said thing. If not, the Java vs. PHP thing is a non issue because said business won't be around for long.

        As for your "Just because there are say, four known responses, it doesn't mean that any of the four are really appropriate for the current user."...you're right. However, if one follows a well designed set of business rules/business processes based on the technically engineered process at hand then the problems with erroneous data making it to the DB is MUCHO reduced (think good design here).

        So you see, proper design + proper tool + simplest implementation/design = success. Do I think Java offers this? Sure, but only in a situation where something in Java is required (make sure it's required or it's only added complexity). Is PHP always the correct choice? No, but then again when one builds a house the saw is not always the correct tool.
        • Hidden variables for session state?
          2003-10-17 16:58:11  anonymous2 [View]

          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.
        • Hidden variables for session state?
          2003-10-17 17:00:15  anonymous2 [View]

          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.
          • 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.
  • Hidden variables for session state?
    2003-10-18 01:53:17  anonymous2 [View]

    No - if you read again: hidden variables for View state, not Session state.

    Put simply how to preserve the state of a complex form, while dealing with validation, perhaps a form of multiple pages (e.g. flight booking).

    >>> The hidden fields are used prior to validation. <<<

    If you're keeping this information in memory or some kind of session store between requests, you're doing things badly wrong and will end up with a) alot of junk in memory for users that didnt come back and b) a whole load of extra processing as you have to re-validate the data on every request until the form is finally complete and c) a whole load of extra complexity in your code to deal with.

    Jeez - this is basic stuff that people learnt with CGI ten years ago.
    • Hidden variables for session state?
      2004-07-06 05:53:54  teejay [View]

      So why not use a cookie instead?


      or better still, do the right thing and use a shared database for sessions.


      If we are talking about decent scaling and reliability, then you want session and state info to be kept at the server to save on a) passing it all back and forth and b) validating it all.


      On any UNIX system it is trivial to store the information in a DB that is shared between multiple webservers. There are lots of ways of making that kind of thing scale to very high levels.


      Hidden variables are a sign that you haven't finished designing your application