scootstah

And what would those be? There is absolutely no reason to store plaintext passwords in the database. When people ask for help here, and we see that they are doing something catastrophically wrong, it is our job to point that out and offer better ways to handle the problem. Storing plaintext passwords is one such situation.

Security questions are very susceptible to social engineering. The only real way to have secure security questions is if the user just types in random, arbitrary data and then keeps it somewhere safe, like a password vault. This means that the user can authenticate themselves with the security questions by providing the stored answers, but noone else is ever going to guess that their mother's maiden name is "asdf9iq459adsfka435dfah". It's true that you shouldn't send plaintext passwords to someone's email, but not for the reason above. In my opinion, whether or not a user's email is compromised is out of your control. Out of convenience to the user, some things just have to rely on the fact that their email is not compromised. Security is often about sacrificing usability. You could make a more secure system that relied on SMS or phone calls to provide authentication, but that is less convenient for the users. The fact that people might use the same password for their bank as they do for your forum is also irrelevant and out of the hands of the developer. You can discourage it, tell them that it's bad, whatever. But, at the end of the day, you have no control over it - so there's no point worrying about it. With that said, sending plaintext passwords to an email is bad, because in some circumstances the email can be intercepted, and the password retrieved. Hashing. Sorry, pet peeve....

I'm curious of your thought process on why you decided to use UNION. UNION is used to combine the results from multiple SELECT's into one result set. So, since you are basically running two SELECT's against the same table with the same criteria, you are getting duplicate results. UNION is absolutely unnecessary for this.

Perhaps you should work on that, then.

Gotta make sure 1 == 1.

No, you don't. You are selecting the number of rows returned, which will never be equal to (string) "true". You have several undefined variables in your script. I tried to rewrite your code, but because of all the undefined and arbitrarily named variables, I cannot. Also, why are you querying the same table to get the same row 4 different times, especially when you have already returned all of the columns in the first query?

I believe you're looking for GROUP BY. SELECT `books`.`title`,`book_purchases`.`book_id`, SUM(`book_purchases`.`price`) as `book_sales_total` FROM `books`,`book_purchases` WHERE `currency`='p' AND `book_id`=`book_id` AND `books`.`id`=`book_purchases`.`book_id` GROUP BY `book_purchases`.`book_id` ORDER BY `book_sales_total` DESC

SHA1 is not secure for password storage. It is a general purpose hashing algorithm used for things like checking file integrity. Also, it makes no sense at all to limit the max password length if you are hashing it. It will always come out to be the same size regardless of the input size.

Second result on Google Syntax new Date() new Date(milliseconds) new Date(dateString) new Date(year, month, day [, hour, minute, second, millisecond]) So, as you can see, Date() will accept milliseconds. A UNIX timestamp is in seconds. So, multiply UNIX timestamp by 1000 and you have your milliseconds. <?php echo '<script>var date = new Date(1346359165 * 1000);</script>';

You get an SQL error because you're not returning the escaped data. Also, I don't really understand the purpose of making a function that returns the data from another function. Why not just use the other function (mysql_real_escape_string()) in the first place? This is another one of those times where someone is trying to mash all of their validation/sanitation into one convenient little place, which you will soon come to realize is just not possible. Your function is now: - Converting HTML to entities - Stripping slashes - Escaping the input What if you had a certain piece of data in which you wanted to convert HTML to entities, and escape the input, but not strip the slashes? Now your function is useless. A super-duper sanitize_all_the_things() function does not exist for a good reason. If you are grouping a bunch of sanitation into one function you are just limiting the usefulness of that function. Now, to answer your original question, you can strip some characters with str_replace. $illegal = array('%', '^', '&'); // place as much as you want in here $str = 'this is % a string ^ with & illegal characters'; $str = str_replace($illegal, '', $str);

If you're using prepared statements and binding the parameters, nothing needs to be done to prevent SQL injection - it is escaped internally. If you weren't using prepared statements, all you would have to do is type-cast the input to make sure it is an integer. Type-casting effectively strips all non-integer characters, and thus it can't be harmful. $number = (int) $_POST['number']; // perfectly safe for SQL

Of course, now more kids are eligible to receive a higher education. Where is the con here? Why? Go ahead, tell us why the ability to program with or without objects is a drawback, instead of a feature. You still haven't answered this yet.

Such as ... ? Or are you just talking out of your ass again?

I'd imagine the chances of supporting that while having cookies disabled is pretty small. Plus, the only thing PHP stores in the cookie is the session ID. I think that a user having cookies disabled is a rare enough event that passing it to the query string is good enough. Or, you could just display a message saying the site will only work properly if they have cookies enabled.

I guess you need the session.use_trans_sid option enabled too.

I think it should be automatic if PHP can't write to the cookie.

Make sure "session.use_only_cookies" is set to 0 in te php.ini

Again, what kind of "system" are you looking for?

Looks like you forgot PHP tags on the "captcha.php" script.

Sounds like as good a place as any, right?

Parking lots are pretty scary even with reverse.

You can specify a timeout for fsockopen.

Well, you could just run in a semi-circle to go the other way.

Neither was the majority of PHP's OOP implementation. OOP existed long before Java did.

At this point, I'm just going to go ahead and confirm that you have no idea what you're talking about.