Oreo

No, the dot is not a separator character. The salt and the hashed password are concatenated together and then base64 encoded. A dot happens to be one of the characters used for base64 encoding, so it could show up anywhere in the string. The only way to separate them is to first extract the salt+hash encoded string from the value returned by hash, which always follows the third $, then base64 decode that, and then extract the first 16 bytes as the salt and the remainder as the hash. At that point you will have two strings of raw binary values which will not render well as ASCII, you would have to base64 encode them again to display them as ASCII. The primary complication with this is that crypt() uses a different base64 encoding alphabet than PHP's base64_encode and base64_decode functions, so you cannot use them for that part of the process. Your system is not using blowfish for some reason and is instead falling back on what looks like standard DES.

makeLinks is not a standard JavaScript function, you cannot pass functions through JSON so it's not coming from Twitter, and there is no attempt to bind item.text.makeLinks to a function in that code. The only way I could possible see this working is if the plugin author had bound makeLinks to the string prototype, but that's not done in the code either. The plugin is either incomplete or has a dependency on some external library that you don't have. You might want to check to see if the plugin author has a working demonstration of this script, as it would show you where makeLinks is defined.

window.open('<?php echo mysql_result($result, $i, 'te_link'); ?>');<?php }?>">link text</a> If that doesn't work, post the output that you are getting.

crypt() doesn't just return a hash of the input + salt, it returns a string that has a bunch of information packed into it, including, at a minimum, the algorithm type, salt and hashed value. The exact format of the string and the information it contains varies from algorithm to algorithm. For blowfish, $hashed in my example would contain four things: an identifier for the blowfish algorithm, the number of rounds run to generate the hash, the salt and finally the actual hash itself. On a similar note, the $salt parameter of crypt() isn't actually just the salt. It needs to be a specially formatted string that contains, at a minimum, the algorithm type and salt. Again, the exact format depends on the algorithm. The fact that the $salt parameter and return value of crypt are compatible formats is the reason my first example works. Another example: echo crypt('abc123', '$2a$04$saltsaltsaltsaltsaltxx'); The salt in this example is the base64 value of the string "saltsaltsaltsaltsaltxx$$" This gives you the output: $2a$04$saltsaltsaltsaltsaltxuK2.MS4sJd6ZjnuS0fp2eenjndo.g4hS You can see how the salt is embedded directly in the output, and how the salt parameter that I passed to crypt() is in the same format as the value that crypt() returned back to me. In both the $salt parameter and the return value of crypt(): $2a$ tells crypt that this is blowfish 04$ tells crypt how many rounds to use saltsaltsaltsaltsaltxx / saltsaltsaltsaltsaltxu is the salt value (more on why this differs in a moment) uK2.MS4sJd6ZjnuS0fp2eenjndo.g4hS is the hashed password One last point of potential confusion is the fact that the final "x" from the original salt appears to be missing and I've listed the "u" that replaced it as belonging to both the salt and the hash in the returned string. This is because crypt() + blowfish uses a 16 byte (128 bit) hash, but saltsaltsaltsaltsaltxx is 132 bits. The final four bits of the last 'x' are truncated, not returned by crypt() and thus not present in the returned version of the hash. For this reason, using "saltsaltsaltsaltsaltxy" as your salt will give you exactly the same output as using "saltsaltsaltsaltsaltxx", but using "saltsaltsaltsaltsaltxA" will give you a different value. It is possible to extract the first 16 bytes of the original salt from the value returned by crypt(), but this is not something you'll probably ever need to do unless you happen to be writing your own implementation of crypt.

Are you sure the code you posted is the same as the code you're running? Because in the code you posted imagettftext has the right number of parameters.

Comment out this line: header("Content-type: image/png"); Then visit the URL of the generated image directly in your browser and see if it spits out any intelligible error messages. Alternatively, save the generated image to your local drive and open it in a text editor. Some other comments: - else branches are not required, if you have nothing to put in them you can omit them completely - there is no particular reason to loop over mysql_fetch_assoc if you're only fetching one result - escape your input to avoid SQL injection exploits: $ServerName = mysql_real_escape_string($_GET['server']);

The generated salt can be easily extracted from the string returned by blowfish, so storing that return value effectively stores both the hashed password and the salt. Consider this example: <?php $hashed = crypt('abc123'); echo $hashed . "\n"; $hashed2 = crypt('abc123'); echo $hashed2 . "\n"; $hashed3 = crypt('abc123', $hashed); echo $hashed3 . "\n"; You'll notice that the first two differ because they have different salts, however the first and the third are the same because in the third call crypt uses the salt that was generated by the first call. No, you should not (intentionally) use the same salt for multiple users. This mostly defeats the purpose of using a salt.

The easiest and most efficient way to get this information would be to query for it directly. You can do this using aggregate and grouping functions in your query. For example: SELECT sport, COUNT(*) as occurrences FROM games GROUP BY sport Will return one row per distinct sport along with the total number of rows with that same value for sport. So something like: sport | occurrences --------------------- baseball | 4 soccer | 2 golf | 6 The MySQL manual has more information on aggregate functions (ie: COUNT) and how GROUP BY works. Your other queries are complicated by the fact that your design has two separate columns for town, but it's still possible to do: SELECT sport, town, SUM(occurrences) as occurrences FROM ( SELECT sport, home AS town, COUNT(*) as occurrences FROM games GROUP BY sport, home UNION ALL SELECT sport, visitor AS town, COUNT(*) as occurrences FROM games GROUP BY sport, visitor ) AS t GROUP BY sport, town; (note: not thoroughly tested) This should give you something like: sport | town | occurrences baseball | Town A | 5 baseball | Town B | 2 softball | Town B | 7 In addition to aggregate functions (SUM, COUNT), this query makes use of subqueries, derived tables and unions.