How do we know the session ID again?


  • Garbage Person

    Sitting here working on this project - most of the early development was done by my team, rather than by myself. Now, however, I am the sole maintainer of this thing.

     Anyway, I noticed this little one liner, repeated over and over throughout our code every time we access the session I.

     

    Here's one usage of it:

    deletecmd.Parameters.AddWithValue("@session", Session("currentSession"))

    I haven't really touched any of that code in quite some time so I've mostly just ignored it. That part of the code works, which is more than I can say for a lot of other things. In fact it looked so innocuous I didn't even stop to take a closer look every time I scrolled by - I just figured we'd done something stupid to the session ID and stored our modified ID in the session itself.

    However, today I was doing some work in one of the page loads and noticed this:

    Session("currentSession") = Session.SessionID

    It's in every page and executed on every load (including postbacks)

     *headdesk*



  • @Weng said:

    Sitting here working on this project - most of the early development was done by my team, rather than by myself. Now, however, I am the sole maintainer of this thing.

     Anyway, I noticed this little one liner, repeated over and over throughout our code every time we access the session I.

     

    Here's one usage of it:

    deletecmd.Parameters.AddWithValue("@session", Session("currentSession"))

    I haven't really touched any of that code in quite some time so I've mostly just ignored it. That part of the code works, which is more than I can say for a lot of other things. In fact it looked so innocuous I didn't even stop to take a closer look every time I scrolled by - I just figured we'd done something stupid to the session ID and stored our modified ID in the session itself.

    However, today I was doing some work in one of the page loads and noticed this:

    Session("currentSession") = Session.SessionID

    It's in every page and executed on every load (including postbacks)

     headdesk

    I don't get it.


  • Garbage Person

     The session (a collection) has an innate property for its own identification string.  However, on every page load, they put that ID into the collection and do all accesses through that mechanism. 



  • @Weng said:

     The session (a collection) has an innate property for its own identification string.  However, on every page load, they put that ID into the collection and do all accesses through that mechanism. 

    Ah, I see. Does the session ever get iterated through in a log dump or anything? If innate properties don't show up in an iterator sequence I could imagine seeing something like


    session.each do |key, value|

    puts key.to_s() + ":" + value.to_s()

    end

    btw I couldn't tell what language your example is written in



  • Maybe it's an attempt by one person to protect against session fixation (assuming somewhere else is code to regenerate the session id if 'currentSession' doesn't exist in the session already). Someone else got the wrong end of the stick and started using it.

    Or maybe it's just a big WTF. 



  •  At least it doesn't affect you. In the past I have raged over stuff like this. I've had major fights with team members when I've seen them write retarded code because I knew that when the time came I'd get the short end of the stick.

    There was tension afterwards, but my timely intervention eventually made the difference between working on decent code and walking into the office with a rifle.



  • @Mole said:

    Maybe it's an attempt by one person to protect against session fixation (assuming somewhere else is code to regenerate the session id if 'currentSession' doesn't exist in the session already). Someone else got the wrong end of the stick and started using it.

    Or maybe it's just a big WTF. 

    Having seen plenty of "select id from table where id = $id" in my day, I can tell you the latter is more likely than you think.



  • @morbiuswilters said:

    Having seen plenty of "select id from table where id = $id" in my day,

    One might almost think that you've retired, or had a career change...

    Of course, I see your 'select id from table...' and raise you a 'select * from table where id = $id' used solely to determine the $id - on a table where the last column is an XML blob which usually exceeds 16k.


  • Garbage Person

    @DOA said:

    At least it doesn't affect you. In the past I have raged over stuff like this. I've had major fights with team members when I've seen them write retarded code because I knew that when the time came I'd get the short end of the stick.

    There was tension afterwards, but my timely intervention eventually made the difference between working on decent code and walking into the office with a rifle.

    This would be rageworthy if I still had a team to fight with. They're all gone - all 17 of them. We hit v1.0 and their involvement ended. Mind you v1.0 was buggy as shit, crashed during the customer demo (we then did a rush patch that same night, but it crashed in EXACTLY THE SAME WAY at the v1.5 demo I gave on Thursday) and the customer hadn't bothered to tell us all of their requirements - some of which I didn't hear about until the v1.5 demo.

     For the record, the reason for the demo crashes was because the usage pattern of our demo didn't match any of the usage patterns hit upon by testing - it was a bug related to the goddamned session. Some state data that should have been cleared on initial pageloads wasn't being cleared - so pages were trying to load each others state and bombing. Which of course is what brought me to post this thread.

     

     



  • @morbiuswilters said:

    @Mole said:

    Maybe it's an attempt by one person to protect against session fixation (assuming somewhere else is code to regenerate the session id if 'currentSession' doesn't exist in the session already). Someone else got the wrong end of the stick and started using it.

    Or maybe it's just a big WTF. 

    Having seen plenty of "select id from table where id = $id" in my day, I can tell you the latter is more likely than you think.


    I use this pattern as a way of asking "does a row with this ID exist?". Is there a better way of doing so?



  • @Carnildo said:

    @morbiuswilters said:

    @Mole said:

    Maybe it's an attempt by one person to protect against session fixation (assuming somewhere else is code to regenerate the session id if 'currentSession' doesn't exist in the session already). Someone else got the wrong end of the stick and started using it.

    Or maybe it's just a big WTF. 

    Having seen plenty of "select id from table where id = $id" in my day, I can tell you the latter is more likely than you think.

    I use this pattern as a way of asking "does a row with this ID exist?". Is there a better way of doing so?

    That's not what this code was being used for.  Personally, I would use "count(*) where id =" or the exists keyword, but your use is fine.  The places I saw this being used, the ID was actually being pulled out.  Even worse, there were places where this was being used but the query had a typo that caused it to error and return no rows ever.  The code required this to happen, though, because when the ID was set, it actually failed.  It's easier to express this in code...

    // $id was already set by this point...
    $res = mysql_query("selcet id from table where id = $id");
    $obj = mysql_fetch_object($res);

    if ($obj->id) {
      // execute code that should never be executed
    }

     

    So when the query was fixed to read "select" rather than "selcet", the code in the if block was executed and the app broke.  The solution was to remove the entire section.



  •  @Carnildo said:

    I use this pattern as a way of asking "does a row with this ID exist?". Is there a better way of doing so?
    Everyone has there own method, mine is usually "select 1 from table where id = $id", but I have seen people use "select id" and then use the id for updating or deleting (they do a "select id..." to determine if the id exists, then "delete from.." to actually delete. I've no idea why they don't just try a delete and see if it fails). 


  • Garbage Person

     select 1 where <blah>
    select count(id) where <blah> if you have an idiotic DB designer who didn't primary key shit and you want to check for corruption on the fly.



  • @Weng said:

     select 1 where <blah>
    select count(id) where <blah> if you have an idiotic DB designer who didn't primary key shit and you want to check for corruption on the fly.

    Presumably an ID would be an auto-increment/serial and thus a PK.  I prefer the count() method because you get back a single result set with a value of 0 or 1 which casts easily into a boolean in a language that does automatic type conversion.



  • @morbiuswilters said:

    @Weng said:

     select 1 where <blah>
    select count(id) where <blah> if you have an idiotic DB designer who didn't primary key shit and you want to check for corruption on the fly.

    Presumably an ID would be an auto-increment/serial and thus a PK.  I prefer the count() method because you get back a single result set with a value of 0 or 1 which casts easily into a boolean in a language that does automatic type conversion.

    Wow.  I really think something has changed with our usual Morbs.  New medication?



  • @Qwerty said:

    Wow.  I really think something has changed with our usual Morbs.  New medication?

     

    He has probably made it through the first phases of menopause and has now come to accept it.


Log in to reply