scootstah

$counter = 1; while($topic = $DB->fetch_row()) { if ($counter == $DB->num-rows()) { echo $counter; } $counter++; }

As you can see here $img = $_GET['img']; $img comes from a query string. So if you're not accessing the page with ?img=blah in the URL, it's not going to be set.

You should post the code so that we can figure out what $img is, and why it isn't being set.

So then obviously $img is empty.

Semi-colons are interpreted by MySQL as the end of a statement, so that won't hurt anything. It will work either way.

Thanks. It is useful. But the main challenge I have is how to approach the web site design when it could be used by R2L or by L2R users. Should I duplicated the pages? this will cause maintenance to be painful. Should I have a parameter which will indicate R2L or L2R and have many IF with in the pages? This will make the code less readable. Is there a recommended solution? If you generate the code with PHP then you can just set the dir attribute.

You don't actually need the surrounding ( )'s. This will work fine: $action = empty($_POST['action']) ? 'default' : $_POST['action'];

You won't be able to using that method, because the page doesn't "reload", it serves a cached version. Usually if there are form errors the form will simply be redisplayed instead of having to go back. And then you can just populate it with values from $_POST.

Are you saving this to a database? Or formatting it on output? If you're saving it to a database and are using mysql_real_escape_string then you'll need to strip them off for output with stripslashes(). If you're not saving it to a database you probably have magic quotes on, so turn that off in the php.ini.

Yes, depending on the character encoding.

Read: http://www.w3.org/International/tutorials/bidi-xhtml/

It's not. That was my point. Does strtotime() not account for this?

What is the charset of the MySQL field?

Assuming you are talking about this, you can use onClose A hook function that will be fired when Shadowbox closes. The single argument of this function will be the gallery element that was last displayed.

A day is never 145440 seconds, it is 86400 seconds.

Not impossible, but very difficult. There is a considerable time and money investment needed to crack it. You would need to allocate a large amount of resources, and frankly script kiddies just aren't going to possess that. So unless you somehow become a huge target, you have nothing to worry about. If you had a website large enough that someone could gain something by attacking it, then they probably wouldn't first try to crack password hashes. Here's a couple of other ways they may gain entry to someone's account: - Figure out a way to get malware onto your website which could infect users with key loggers and such - Phishing or other social engineering to get people to give their password away - Brute force or using a dictionary attack on the login - SQL Injection - Session hijacking

time(); It's just numbers, so no worries there. Well, you could generate a quick hash or something with microtime(). Unless two users register at the same microsecond, it should be unique. If you're concerned you can make it further unique by meshing it with parts of the users info. IE, their email, IP, username, etc.

Oops, just noticed a typo in my code. At the top, $result = mysql_query("SELECT * FROM $tbl"); should be $result = mysql_query("SHOW FIELDS FROM $tbl");

The length and randomness of the salt is an unknown factor. I don't think it is technically feasible to generate a rainbow table that not only hashes every possible permutation of the ASCII table, but also generating it with every possible permutation of the ASCII table attached to it. You are talking about an astronomical file size, not to mention the YEARS it would take to do such a thing. Put simply: this isn't going to happen anytime soon. It is certainly a viable choice. I think bcrypt was designed specifically for hashing passwords. All I could find about PHPass being cracked is a brute force tool was released for it. Not a big deal really. I don't think you have anything to worry about. Yeah it should be a random string, but other than that nothing special. You can use this website to generate strings.

ugh. So theres no way to identify a field type inside the loop, field by field?? No, but you could do something like this. $result = mysql_query("SELECT * FROM $tbl"); $fields = array(); while($row = mysql_fetch_assoc($result)) { $fields[$row['Field']] = $row['Type']; } $sql = "SELECT * FROM $tbl "; $result = mysql_query($sql) while ($line = mysql_fetch_array($result, MYSQL_ASSOC)) { if ($row == 1) { foreach ($line as $col_key => $col_value) { echo "<b>".$col_key. ":</b> "; echo "field is ".$fields[$col_key]; ?><input type="<?php if ($col_key=='password'){echo 'password';} else {echo 'text';}?>" name="<?php echo $col_key;?>" value="<?php echo $col_value;?>" /><br/><?php } } } mysql_field_type does not return the actual field type, just a generalization. For example, tinyint, smallint, mediumint, int, and bigint are all classified as "int".

That's not how it works. The hash would be different with a salt. Let me show you an example using MD5 (for simplicity). Let's say we have these users: mysql> select * from users; +----+------+----------------------------------+------------+ | id | name | password_hash | salt | +----+------+----------------------------------+------------+ | 1 | bob | 8542aac12095692451d03024c1a4aac3 | kdo50fda65 | | 2 | joe | 93c7284d2e1bb88cb92e5587d07e7ef3 | 9klr4nvzw0 | +----+------+----------------------------------+------------+ 2 rows in set (0.00 sec) Now, bob's password is "banana" and joe's password is "popsicle". The password_hash that you see is a combination of the plaintext password and the salt, IE: md5(bananakdo50fda65) If I don't use a salt (as would be the case if you downloaded a rainbow table), the hashes would look like this: md5(banana) - 72b302bf297a228a75730123efef7c41 md5(popsicle) - a0c73d7e9b0192500f2b9b16e575e89f As you can see, they are not the same as the user's actual password hash. So simply downloading a rainbow table won't do you any good. It's possible that you could find a collision in the rainbow table but like I said, using better algorithms makes this very very unlikely. A salts length or complexity really has no bearing on anything. The fact still remains that you need a rainbow table for each individual user. The salt could be 1 character, and you would still need a rainbow table for every user. Maybe 100 years in the future when 500 Exabyte hard drives are the norm you can worry. But not for now. I'm not a cryptographer, so I'm not really sure. All I know is that you don't have to worry about it. I'm pretty sure sha512 has not been broken yet, so until that happens, you're fine. And when and if that happens, a better hashing algorithm will take its place. Well, typically the more bits the slower it would be. That's not the only deciding factor, of course. Some hashing algorithms (like md5) are not built for security at all but for signature. For example, an md5 checksum of a file, so you know the contents of the file haven't been tampered with. If you want uber slow, go with blowfish/bcrypt. You can use PHPass to implement it. It doesn't truncate anything. There is no size constraint. Yes. In your above example, if someone's password was really "Guess" but "secure" generated the same hash, then either of those would log the person in. Since on the back end you are simply comparing hashes, so it wouldn't know the difference. Sure. The only way anyone would see it would be to gain access to the server and download the file. Right. 30-60 characters or so. Not really, other than wasting memory/storage space if you have ridiculously long strings.

Did you even try my code? You can make that much cleaner like this: $middle_column = '<form method="post" action=""> <fieldset id="contactform"> <legend>Renovations & Consultations</legend><span id=errors>'. $error_message .'</span><div class="row_div"> <div class="label_div"> <label>First Name:</label> </div> <div class="input_div"><input name="First Name" type="text" maxlength="50" size="50" value="' . (!empty($_SESSION['First_Name']) ? $_SESSION['First_Name'] : '') . '" /></div> </div> </fieldset> </form>';

No i want the field type for each field as I loop through them (I'm making a generic form so I want the input types to reflect the field type - so a text box will be used if the field type is text etc) That query is the only way you're going to find out its type. You'll have to run that query ahead of time, make an associative array of the field names and their types, and then use that later when you're looping through results.

You can use this query: SHOW FIELDS FROM table

The source surrounding (and including) the anchor tags.