• illum (unregistered) in reply to Dark
    Dark:
    // Make a random string, 7 characters long
      $i = 0;
    
      while ($i <= 7) {
    

    ...

         $i++;
    
      }</div></BLOCKQUOTE> FYI: that makes an 8 character string...
    
  • Dark (unregistered) in reply to illum
    illum:
    FYI: that makes an 8 character string...
    Cool, I missed that :) I'm so used to < conditions that I overlooked the <= condition here.
  • (cs) in reply to Martin
    Martin:
    I just quitely replaced it with content.php?rnd=<?php echo time(); ?>.

    This will be the future thread on Daily Advanced WTF 2.0

    ... I just quitely replaced it with content.php?rnd=<?= time() ?>

    Which would actually be a WTF, since short tags have apparently been depreciated to avoid language conflicts.

    I've not studied it too long, but as for the original code, this is an interesting point....

    The commenting: serious wtf The exact calls: interesting ... but only slightly broken ... the cast should simply discard everything after the the first non-numeric character and return the first part (atoi style) and in this case that is the ms component, which is a good random seed candidate. The concept: spot on. To me this looks like a text book (if a little long winded) method of generating a random string of characters conforming to a predictable character set.

    The only thing questionable is the logic for using it, but if someone loads pages fast, they could experience caching issues, so this method would, technically speaking, be more reliable.

    To other commenters...

    Pete from Perth:
    Probably easier to simply send the header or meta strings needed properly rather than resort to this sort of ugly hack.

    Ah, if only this were true. As has been pointed out multiple times, not all browsers pay attention to this, and worse, ISP level proxies don't always pay attention to the caching headers. Don't ya love people that don't follow standards?

    Mork:
    though it does smell a little of security through obscurity.

    The use here is not consistent with the proper definition of salt though, so I imagine the original author got confused somewhere along.

    Again, as pointed out, the purpose of salt is to prevent someone using a rainbow table to break a hash.

    And in this case, I think the use does conform to the definition, since it is a string being used to influence the transformation process between the source and digest.

    byron:
    generally i use the last modified time of the file in question rather than the current time. let the browser cache it if it hasn't changed.

    Yes well, dynamic content and ISP level caches... do I need to elaborate further?

    And now for the fun one ...

    Dark:
          // The characters from which the random code is made.
          // The string is called $salt because I read
          // a cryptography book once.
          $salt = "abcdefghijklmnopqrstuvwxyz0123456789";
    
    Ok, so "source pool" or "secret" or something might have been better, but as I said, I think salt is close enough to being valid in this case.
          // Reinitialize the random generator every time through
          // because I bet it would otherwise start repeating
          // itself when I'm not looking.
    
    Ah, isn't ignorance bliss? Unless I'm much mistaken, pre 4.2, s/rand() behaved exactly like C's s/rand() ... meaning that every start up, the seed was set to 0, and the same sequence of numbers is generated. In any case, calling srand() is both sensible and properly backward compatible.
          // Since srand expects an int, passing microtime()
          // directly would always get truncated to 0 and
          // that would be embarrassing.
          // Use double-size math because we care deeply
          // about the precision of our random numbers.
    
    Wait, what's a wtf in this? You have a better way of turning a string 0 <= x < 1 in to an int than, atoi-esq cast, multiply, implicit cast? And for anyone wondering, this is technically less predictable and more reliable for this purpose than seeding from time(), since two calls in the same second would get the same random string...
             // Generate a random number suitable for indexing
             // $salt. Use a simple modulo because we're not
             // really serious about the whole random thing,
             // so it doesn't matter that the resulting
             // distribution is skewed towards 0.
             // Also, calling rand(0, 32) seemed too complicated.
             // Use modulo 33 because $salt is 36 characters
             // long and the numbers 7, 8 and 9 traumatized me
             // when I was young.
    

    Wait .... To simplify the process here... You have a number between 0 and 999,999 ... if you do 999,999%33, you get 0... 30,303 * 33 == 999,999... so that means that you have an extra 0? How big is that skew? 0.003%?

    A truly random number source has a bigger skew than that.

    The irony is, of course, that in the very next breath you mention the fact that we're not using mod 36 here, when that would introduce a far bigger skew.

             // Building strings one character at a time
             // builds character.
    
    Care to suggest a better way? Assign to an array and join it maybe? Have 7 temp vars knocking around and concat them in one go?

    Done much C lately?

       // Make sure it doesn't throw an error
       // like the last time I edited it.
       // Also, it would be a pity to leave
       // without polluting the global namespace.
       $random = make_random_code();
    
    One would assume that it is there for the purpose of demonstration?

    That was a nice rant.

    I'm sure this won't get featured since it's waaaay too long, but hey, that's life.

    And for the record, The Real WTF is the comments we generate here... and the number that open their mouths without thinking first. Occam's Razor may prompt you to assume incompetence in something you don't understand, but never forget there might be a good reason for something strange.

  • Andrew (unregistered) in reply to MrBushido
    MrBushido:
    What's sad is that a while ago a coworker of mine did pretty much the same thing, though I'd say on a much worse scale. Here's what I managed to dig out of the repos
    public static function getRandomString($length)
            {
                    if($length>0) 
                    { 
                      $rand_id="";
                       for($i=1; $i<=$length; $i++)
                       {
                         mt_srand((double)microtime() * 1000000);
                         $num = mt_rand(1,36);
                         $rand_id .= self::_assign_rand_value($num);
                       }
                    }
    
                return $rand_id;
        }
    
        private static function _assign_rand_value($num)
        {
          // accepts 1 - 36
                switch($num)
                {
                        case "1":
                         $rand_value = "a";
                        break;
                        case "2":
                         $rand_value = "b";
                        break;
                        case "3":
                         $rand_value = "c";
                        break;
    

    .. etc etc to end of alphabet and beyond

    Ah, I get it - TRWTF is that he forgot to do the dictionary lookups to make sure there weren't any rude words in the random string. Maybe that's why they call it "salty language"..

  • adiener (unregistered)

    The comments! They burn!

  • Marcos (unregistered)

    // set i = 0 $i = 0;

    Gee thanks so much!

  • fzamora (unregistered)

    WTF. your code is not going to be as tasty without the salt. You should consider using less pepper (comments) though.

  • Franz Kafka (unregistered) in reply to Bob Marley
    Bob Marley:
    The real WTF is that a programmer would go quietly change code without enquiring why it was that way, worst case is there's no good reason and someone learns something, worst case just quietly changing it is you reintroduce a bug that someone had fixed, do that a couple times with me and you'd be getting the boot rather fast. So go learn how to work as a team.

    can i have a drum roll too please?

    Been there, did that. I had a cow orker that would argue any change from the status quo until I got tired (he didn't debate, just brought up the same argument and tried to talk me to death), so when I found brain damage in the code, I could either argue for a month and get nothing done, or just fix it and have it go in.

    Another irritating habit: discuss some change, get him to agree to do it a certain way, and have him go back and do it his way anyway.

  • (cs)

    The real wtf is that instead of using rand they should have used mt_rand. Duh!

  • (cs)

    Favorite comment of all time:

    // Do while i <= 7
    while ($i <= 7) {

    2nd favorite:

    // Increment i by 1
    $i++;

    Great!

    }

    (couldn't leave it open)

  • lukas (unregistered)

    | Why seed the randomizer with (double)microtime()*1000000, | when microtime() already returns a string that looks | like '0.53138500 1203062920'? Why srand - which is | basically deprecated as of PHP4, and accepts an int

    Because PHP will evaluate it like this:

    '0.53138500 1203062920' * 1000000 => 0.531385 * 1000000 => 531385

    This part actually looks ok to me.

  • Dark (unregistered) in reply to Nazca

    Hi Nazca! Thanks for the analysis.

    First, I'd like to say that not all of my comments were intended to mock. I really was trying to represent the process of thought that might have produced that code, and there were some good things in there.

    Nazca:
    Again, as pointed out, the purpose of salt is to prevent someone using a rainbow table to break a hash.

    And in this case, I think the use does conform to the definition, since it is a string being used to influence the transformation process between the source and digest.

    But this one is always the same string, which makes it not a salt. The whole point of a salt is that it's different for every use.
    And now for the fun one ...
    Thanks, I try :)
    Nazca:
    Dark:
          // The characters from which the random code is made.
          // The string is called $salt because I read
          // a cryptography book once.
          $salt = "abcdefghijklmnopqrstuvwxyz0123456789";
    
    Ok, so "source pool" or "secret" or something might have been better, but as I said, I think salt is close enough to being valid in this case.
    $source could work. $secret could not, because everyone knows the alphabet, and nothing in this function relies on it being secret. $salt is wrong because it has a definite meaning and this is not it, so using that name will mislead readers. Personally I would have gone for $alphabet. Not in the sense of our alphabet a-z, but in the sense of being the set of symbols for this algorithm. Well, in theory. In practice I would just use $s because it's short :)
    Nazca:
    In any case, calling srand() is both sensible and properly backward compatible.
    Yeah, but calling it before every use is not. srand() should be called once, at startup. Having srand() inside the function will actually degrade randomness if you call the function twice.
    Nazca:
    [about microtime()...]

    Wait, what's a wtf in this?

    No wtf in the code. This was my stealth way of answering some of the questions of the submitter, which had a wtf factor of their own :)

    Nazca:
    Wait .... To simplify the process here... You have a number between 0 and 999,999 ... if you do 999,999%33, you get 0... 30,303 * 33 == 999,999... so that means that you have an extra 0? How big is that skew? 0.003%?
    The skew is small, but it just annoys me when people don't get it right. It's one of my pet peeves, especially since I play online strategy games :) And it can have a big effect when you're working with individual random bytes, so it's a pattern to be suspicious of.

    The PHP docs say that RAND_MAX might be as low as 32768. But to my surprise, assuming they mean 0 to 32768 inclusive (which is a bit weird), it turns out that that particular range doesn't have any skew when taken modulo 33! Maybe this explains why the code doesn't use 36 :)

    Nazca:
             // Building strings one character at a time
             // builds character.
    
    Care to suggest a better way? Assign to an array and join it maybe? Have 7 temp vars knocking around and concat them in one go? Done much C lately?
    Oh I don't exactly disagree with this method, I just couldn't resist the pun :) When you're building a string this short it probably doesn't matter what method you use. But PHP does allow something like this, similar to how you'd do it in C:
    $s = "12345678"; // preallocate string
    for ($i = 0; $i < 8; $i++) {
        $s[$i] = next_char();
    }
    
    Nazca:
    Occam's Razor may prompt you to assume incompetence in something you don't understand, but never forget there might be a good reason for something strange.
    That's why good commenting is so important, though! For example, there should have been a comment somewhere that explained why the NoCache parameter was needed at all, and which browser specifically caused the problems. That allows future developers to test new pages against that browser, and check if it's still relevant. Not having such comments means that new developers have to keep copying the old code without knowing why, which leads to cargo cult programming.

    I've seen my share of /* Do not delete the following line!!! */ followed by a nonsensical line, and surrounded by a page full of hacks to keep the rest of the code working in the presence of that nonsensical line. Presumably the line made some sort of sense, eight years ago.

  • Jason (unregistered) in reply to Bob Marley
    Bob Marley:
    The real WTF is that a programmer would go quietly change code without enquiring why it was that way, worst case is there's no good reason and someone learns something, worst case just quietly changing it is you reintroduce a bug that someone had fixed, do that a couple times with me and you'd be getting the boot rather fast. So go learn how to work as a team.

    can i have a drum roll too please?

    The phrase "previous developers" indicates to me that there may not be anyone around to ask why they did so. Just to give them the benefit of the doubt.

  • someone (unregistered)
    src="content.php?NoCache=<?php $random = make_random_code(); echo("$random"); ?>"
    Yes, because
    src="content.php?NoCache=<?php echo make_random_code(); ?>"
    or even
    src="content.php?rnd=<?=make_random_code();?>"
    are so hard to type.

    Actually

    src="content.php?NoCacheThisPageBecauseIAmStupid=<?php /*generate a random string: */ $strRandomStringVariable=make_random_code(); /* convert random string function result into a string: */ $strRandomStringVariable=strval($strRandomStringVariable); /* add random string variable to URL parameter (making sure to encase the variable unnecessarily with double quotes and curly braces): */ echo("{$strRandomStringVariable}"); </div>
    would be a Brillant! and enterprisey solution guaranteed to work in all of our top-quality codebases!
  • Mike (unregistered)

    For the folks calling this dubious, I'd agree on some level; it's not a real WTF, but more of a noob issue (i.e., not understanding what is built in to the language). The whole thing could have been done more succinctly, albeit a little more verbose than the example below (the ASCII table has some non-URL-safe characters between 48 and 122, so there would need to be a check for that):

    $str = '';
    
    for ($i = 0; $i < 7; $i++)
         $str .= chr(mt_rand(28, 122));
    

    Far from perfect, but the point is the only WTF is either not being seasoned enough to know what the lang is capable of (something that only comes with time, so not really a WTF) or failing to find a better way of doing something that is, at a theoretical level, perfectly valid (something that can only be chalked up to laziness, which is the worst kind of WTF).

    captcha = jumentum (or "momentum as it applies to the Hebrew population")

  • Joel (unregistered)

    I've had the displeasure of working on code commented like this code. I honestly don't understand what motivates people to put in comments like

    // set i to 0 $i = 0;

    Are you just commenting those lines so that you can say that you comment your code? Why don't you comment the reasoning behind your bat-shit insane algorithm instead of giving me a lecture on how variable assignment works in the particular language that the code is written in?

  • Boner (unregistered) in reply to me
    me:
    I just quitely replaced it with content.php?rnd=<?php echo time(); ?>.
    Thus demonstrating that you have no more clue than the author of that abomination. I don't say that everybody has to know about how to control caches in HTTP (although not knowing HTTP basics speaks volumes about your competency as web apps developer, even a newbie should study it a bit), but any programmer worth being called that should immediately realize that this problem must be common and there's almost certainly a proper solution to it that they should use instead of ugly hacks like adding time() to URL.

    Look at the big brain on Brad!!!

  • Guest (unregistered)

    The Real WTF is use of PHP

  • (cs) in reply to Dark
    Dark:
    Hi Nazca! Thanks for the analysis.

    First, I'd like to say that not all of my comments were intended to mock. I really was trying to represent the process of thought that might have produced that code, and there were some good things in there.

    Fair point ... I was rather grumpy when I replied, so that might have made me seem overly harsh hehe.
    Nazca:
    Again, as pointed out, the purpose of salt is to prevent someone using a rainbow table to break a hash.

    And in this case, I think the use does conform to the definition, since it is a string being used to influence the transformation process between the source and digest.

    But this one is always the same string, which makes it not a salt. The whole point of a salt is that it's different for every use.
    Kinda ... the point of salt is not that it's different for every use, but that it is there.

    Lets say I have a password database and one of my users has the password "Dancer365" ... if all the passwords use the same salt that still means the attacker has to generate an entire rainbow table to get a match (or collision). Using the same salt does defeat part of the point, but not the whole point.

    And now for the fun one ...
    Thanks, I try :)
    hehe :)
    Nazca:
    Dark:
          // The characters from which the random code is made.
          // The string is called $salt because I read
          // a cryptography book once.
          $salt = "abcdefghijklmnopqrstuvwxyz0123456789";
    
    Ok, so "source pool" or "secret" or something might have been better, but as I said, I think salt is close enough to being valid in this case.
    $source could work. $secret could not, because everyone knows the alphabet, and nothing in this function relies on it being secret. $salt is wrong because it has a definite meaning and this is not it, so using that name will mislead readers. Personally I would have gone for $alphabet. Not in the sense of our alphabet a-z, but in the sense of being the set of symbols for this algorithm. Well, in theory. In practice I would just use $s because it's short :)
    Everyone knows the alphabet, but not everyone knows that $secret contains that. It could be really well shuffled. Trivial to guess, but still secret. Point about it not needing to be secret, though I still defend the validity of using the term salt for this. For the rest, I agree.
    Nazca:
    In any case, calling srand() is both sensible and properly backward compatible.
    Yeah, but calling it before every use is not. srand() should be called once, at startup. Having srand() inside the function will actually degrade randomness if you call the function twice.

    mmm, not really... Calling it before each use makes sure that it has actually been called rather than simply assuming the right header got included (from the tone of the OP, I'd say that's probably not a safe assumption) Degrading randomness... any instruction consumes time ... the chances of getting the same seed again is 1,000,000:1 ... I haven't actually tested the effect on randomness by repeatedly seeding the prng, but I would guess the numbers would be less predictable if nothing else.

    Nazca:
    [about microtime()...]

    Wait, what's a wtf in this?

    No wtf in the code. This was my stealth way of answering some of the questions of the submitter, which had a wtf factor of their own :)
    Ah, fair enough :)

    Nazca:
    Wait .... To simplify the process here... You have a number between 0 and 999,999 ... if you do 999,999%33, you get 0... 30,303 * 33 == 999,999... so that means that you have an extra 0? How big is that skew? 0.003%?
    The skew is small, but it just annoys me when people don't get it right. It's one of my pet peeves, especially since I play online strategy games :) And it can have a big effect when you're working with individual random bytes, so it's a pattern to be suspicious of.

    The PHP docs say that RAND_MAX might be as low as 32768. But to my surprise, assuming they mean 0 to 32768 inclusive (which is a bit weird), it turns out that that particular range doesn't have any skew when taken modulo 33! Maybe this explains why the code doesn't use 36 :)

    Ah dear ... looking at what you quoted me as saying, I clearly wasn't paying attention and stuffed it up lol. I actually did math for someone performing modulo of the seed value, which is simply stupid. I'll take your work for 32767%33.

    Of course we could be missing the simple answer that somewhere in the process of typing the OP, someone hit 3 instead of 6 on the numpad :p

    Nazca:
             // Building strings one character at a time
             // builds character.
    
    Care to suggest a better way? Assign to an array and join it maybe? Have 7 temp vars knocking around and concat them in one go? Done much C lately?
    Oh I don't exactly disagree with this method, I just couldn't resist the pun :) When you're building a string this short it probably doesn't matter what method you use. But PHP does allow something like this, similar to how you'd do it in C:
    $s = "12345678"; // preallocate string
    for ($i = 0; $i < 8; $i++) {
        $s[$i] = next_char();
    }
    
    hehe, yes, that would work at that ... though it's not as clear as the string concat ... though ... isn't it $s{$i}? meh, can't really remember.
    Nazca:
    Occam's Razor may prompt you to assume incompetence in something you don't understand, but never forget there might be a good reason for something strange.
    That's why good commenting is so important, though! For example, there should have been a comment somewhere that explained why the NoCache parameter was needed at all, and which browser specifically caused the problems. That allows future developers to test new pages against that browser, and check if it's still relevant. Not having such comments means that new developers have to keep copying the old code without knowing why, which leads to cargo cult programming.

    I've seen my share of /* Do not delete the following line!!! */ followed by a nonsensical line, and surrounded by a page full of hacks to keep the rest of the code working in the presence of that nonsensical line. Presumably the line made some sort of sense, eight years ago.

    Yes, cargo cult programming is alllllways fun hehehe. Definitely agreed, though the problem is that the software it would have problems with is likely many and obscure :(
  • Rourke (unregistered) in reply to Dark
    Dark:
             // Use modulo 33 because $salt is 36 characters
             // long and the numbers 7, 8 and 9 traumatized me
             // when I was young.
             $num = rand() % 33;
    

    I startled my coworkers with my fit of audible mirth on reading your post. This part in particular, is obviously a reference to the old joke:

    Why is 6 scared?

    Luvverly captcha for Latin scholars like me: consequat

  • ZiggyFish (unregistered)

    // Ask WTF Anthony was thinking Is this WTF meant to be the code or, the solution Anthony C came up with?

    // Really what was he thinking I fixed the symptom not the problem it's self.

  • Ray (unregistered) in reply to Rourke

    Firefox has an awful caching system.

    http://particletree.com/notebook/firefox-caching-issues/

    I'm generating dynamic images through php (charts/graphs) and firefox refuses to acknowledge the http headers.

    Random request strings like these are the only way to get it to behave.

  • cangulo (unregistered) in reply to Bob Marley
    Bob Marley:
    ...snip... you reintroduce a bug that someone had fixed ...snip...

    ... the bug being "Not enough bad style and useless code".

  • ZiggyFish (unregistered) in reply to Rourke
    Rourke:
    Why is 6 scared?

    cos seven ate nine's mum

  • Tom_fan_63 (unregistered) in reply to Dark
    Dark:
    I think we have agreement that the comments were the most WTFy part. So I fixed the comments:
    <?php
       // Create a string-token that is
       // (a) impossible to predict and
       // (b) different for every request 
       // Both requirements are taken more seriously than is
       // usual for PHP code. Instead of half-assed, this will
       // be done fully-assed.
       function make_random_code() {
          // The characters from which the random code is made.
          // The string is called $salt because I read
          // a cryptography book once.
          $salt = "abcdefghijklmnopqrstuvwxyz0123456789";
          // Reinitialize the random generator every time through
          // because I bet it would otherwise start repeating
          // itself when I'm not looking.
          // Since srand expects an int, passing microtime()
          // directly would always get truncated to 0 and
          // that would be embarrassing.
          // Use double-size math because we care deeply
          // about the precision of our random numbers.
          srand((double)microtime()*1000000);
    <pre>  // Make a random string, 7 characters long
      $i = 0;
      while ($i <= 7) {
         // Generate a random number suitable for indexing
         // $salt. Use a simple modulo because we're not
         // really serious about the whole random thing,
         // so it doesn't matter that the resulting
         // distribution is skewed towards 0.
         // Also, calling rand(0, 32) seemed too complicated.
         // Use modulo 33 because $salt is 36 characters
         // long and the numbers 7, 8 and 9 traumatized me
         // when I was young.
         $num = rand() % 33;
         // Extract the somewhat-randomly chosen
         // character from $salt.
         $tmp = substr($salt, $num, 1);
         // Building strings one character at a time
         // builds character.
         $random_code = $random_code . $tmp;
         $i++;
      }
      return $random_code;
    

    }

    // Make sure it doesn't throw an error // like the last time I edited it. // Also, it would be a pity to leave // without polluting the global namespace. $random = make_random_code(); ?>

    This are the best comments I've never seen in a piece of c.... code ;-)

  • Sandor (unregistered)

    no caching? maybe this is a solutiion:

    <meta http-equiv="Cache-Control" content="no-store, no-cache, must-revalidate, post-check=0, pre-check=0"> <meta http-equiv="Pragma" content="no-cache">
  • Jasper (unregistered)

    I love these incredibly useful comments in the code:

    // Set i = 0
    $i = 0;
    
    // Do while i <= 7
    while ($i <= 7) {
    
    // Increment i by 1
    $i++;
  • wtf (unregistered)

    Haha, the poster of this also made a WTF! He should have used the shortcut, <?=time()?> Better yet, he should have dropped that from the url entirely, and instead make sure the referred php script sent the proper no-cache headers.

  • Konamiman (unregistered)

    http://en.wikipedia.org/wiki/Salt_(cryptography)

  • (cs) in reply to http://jobs.thinkaloud.in
    http://jobs.thinkaloud.in:
    I know another term that will act as "an extra obstacle for people trying to recover the original value, though it does smell a little of security through obscurity. "

    its called PEPPER

    PEPPER is generally usefull to keep people from getting too nosy ;-)

    Da' Man

  • (cs) in reply to Guest
    DOA:
    Now taking bets on how long it'll take for some dweeb to helpfully inform us that "PHP is the real WTF"
    Guest:
    The Real WTF is use of PHP
    *sigh*
  • Troll mode on (unregistered)

    Guys string is 8 character string, because it's from 0 to <=7 including, Making all your sarcasm a BS

  • (cs) in reply to Jasper
    Jasper:
    I love these incredibly useful comments in the code: (---snip---)
    Read the other coments before posting?
    wtf:
    Haha, the poster of this also made a WTF! He should have used the shortcut, <?=time()?> Better yet, he should have dropped that from the url entirely, and instead make sure the referred php script sent the proper no-cache headers.
    No, seriously guys, read the other comments before posting, you just sound dumb repeating what everyone else said
    Konamiman:
    http://en.wikipedia.org/wiki/Salt_(cryptography)
    *Sigh* fine, just post a reply without reading the comments - obviously no-one else could possibly have thought of a comment as witty and Brillant! as yours, and even if they did it won't detract from how smart you look...
    Sandor:
    no caching? maybe this is a solutiion:
    <meta http-equiv="Cache-Control" content="no-store, no-cache, 
        must-revalidate, post-check=0, pre-check=0"> 
    <meta http-equiv="Pragma" content="no-cache">
    Yes, that'll work - we all know that caching servers and caching proxies parse all HTML files they receive to check for meta tags that set html headers. Wait, they don't? This method will only work for client-side browser caching? Bugger...

    Addendum (2008-05-13 06:10):

    • html headers, + http headers. Sorry, still haven't woken up (only 2 cups of coffee)
  • Paolo G (unregistered)

    Anthony C said, "I decided against [...] even trying to figure out why my predecessors chose such an elaborate routine to generate a random string to prevent a browser from cacheing."

    Is Anthony one of those people who thinks that "cache" is pronounced in the same way as "cachet"? Maybe he meant to write "cachéing" :)

  • Andrew (unregistered)

    A salt is used to protect against dictionary attacks.

    (From Google): "A seed value used in the encryption of a plaintext password to expand the number of possible resulting ciphertexts from a given plaintext. The use of a salt value is a defensive measure used to protect encrypted passwords against dictionary attacks."

    Incorrect use in that context though.

  • TInkerghost (unregistered) in reply to me
    me:
    I just quitely replaced it with content.php?rnd=<?php echo time(); ?>.
    Thus demonstrating that you have no more clue than the author of that abomination. I don't say that everybody has to know about how to control caches in HTTP (although not knowing HTTP basics speaks volumes about your competency as web apps developer, even a newbie should study it a bit), but any programmer worth being called that should immediately realize that this problem must be common and there's almost certainly a proper solution to it that they should use instead of ugly hacks like adding time() to URL.
    I'll echo some other people here --- what should happen with a cache & what does happen with a cache are sometimes different. While any caching server/browser should acknowledge & honor an expiration time in a header, they sometimes do not - wrong timestamp, can't be bothered, think they know better, whatever. In those cases, the only way to force a no-cache is to alter the URL. The correct fix is to fix the caching server, however, that is not always an option. Hence - ugly HTML hacks in the URL
  • Ron (unregistered) in reply to http://jobs.thinkaloud.in

    Well, a "salt" could be a prefix string when using hashing. For example, in the unix passwd file, the hash values for user passwords are in fact not just directly the hash of the passwords, but the passwords prepended with salt (ok, may not work it exactly this way, but this is the idea).

    So a salt could be a "randomizer string" in this sense.

  • (cs) in reply to Ron

    // Set i = 0 $i = 0;

    What I especially love about this wtf is how if you change the assignment you must update the comment.

    // Set i = 0 $i = 1;

    OOPS THE COMMENT MAY CAUSE A BUG NOW.

  • (cs)

    Yes, gotta love the people that continue to post the same stupid answers without reading the comments and seeing that they've already been talked to death.

  • Belwood (unregistered) in reply to Dark

    Salt is an old-ish term. I think it was mostly used with the crypt(...) system call in *nix systems.

    http://en.wikipedia.org/wiki/Crypt_(Unix)

  • (cs)

    So uh... what happens if the request is made more than one time in a second with the proposed fix?

  • Rasmus Kaae (unregistered)

    Why not simply use rand() instead of all the hickups mentioned here?

    The pattern of adding something random to a query-string makes perfect sense to me. Using time()-also makes sense. Perhaps even md5(rand()) would make it for a nice string :-)

  • kkl (unregistered)

    Use of time() to prevent caching is a WTF on its own. There's Cache-control:no-cache for this purpose and it doesn't pollute caches with never-reused copies. I'm browsing on a mobile device with limited cache capacity you insensitive clod!

  • (cs)

    Its also not truly a random value that its generating. 33 doesn't evenly divide 1000000, so 'a' is going to be a more common character than the others. Which is a bit scary, as the term 'salt' implies the original developer thought they were doing something involving cryptography.

  • df5 (unregistered) in reply to Derek

    Yes, if the same user requested the same page twice at the same time from the same browser session, then yes, the time method would "fail".

    So in reality, it's ok.

  • Code Guy (unregistered) in reply to Andrew

    That's from the old school of structured programming. Where you actually write down what you want to do in human language before you try to code it. I'd rather have lots of silly comment than no comments at all.

    You can say "Don't comment your code, code your comments." But no one does.

  • Luc Golden (unregistered) in reply to Dark

    The real WTF is that you don't understand at all HTTP. Add cache control rules to the HTTP output and drop that bloody stupid & broken workaround.

  • (cs)

    Regarding the author's interesting choice of variable nomenclature and strange behavior building a string one character at a time with a loop (I know know PHP, but I think that's what they're doing... right?)...

    The term "secret salt" is used in cryptography as "random bits that are used as one of the inputs to a key derivation function." Check out salt in wikipedia.

    As for why to build a random string one character at a time, I would guess has to do with harvesting the most entropy.

    What this author is doing kinda makes sense to me as an effort to improve the quality of their random numbers, but it seems like it's just a bit of overkill to make certain of the randomness to this degree. But then again, I don't really understand the problem, so maybe there's a good reason they're doing it.

    Addendum (2008-05-22 16:44): And sorry if this covers some ground that was already covered, the last thing I read was something about Pepper before I actually posted mine, and there are a lot more comments now.

  • Chris 'Xenon' Hanson (unregistered)

    Salt is a cryptographic term for randomness used in one of several cryptographic contexts: http://en.wikipedia.org/wiki/Salt_(cryptography)

  • F Solomon (unregistered)

    Yes, while the original code may not be perfect, it is much more suitable for an environment where a web browser or other caching application may be polling this page (although, admittedly, there are simpler/better ways to do this).

    Your solution is not one of the better ways. If the content of the page can change on a per-request basis, and you are serving multiple simultaneous clients, it is possible for your code to allow for cached results. For instance, many ISPs, and even small business intranets sometimes, have their own web proxies. Two clients (or one client querying the page twice) could potentially result in a cache match if you are just using time(), and result in a cached return rather than a live one. I'm not sure what context this code is called in, but I think the previous developer could have been planning for this eventuality.

    I've seen this happen in production environments using exactly the kind of "fix" you put in, and it just doesn’t work well for heavily hit systems.

Leave a comment on “A Rather Curious Pattern”

Log In or post as a guest

Replying to comment #:

« Return to Article