As long as you are basically learning fresh, use PDO instead of Mysqli. You can download my PDO Bumpstart database from my signature to get you going. It has a handful of basic things you would be doing. You will be up and running in a minute.
I will get their Kevin.
What are the advantages of PDO prepared statements over mysqli prepared statements?
My logic is I am trying to learn off of something I already know, mysql and mysqli are simular enough I easily pick up the new concepts. So is there enough of an advantage with PDO to throw another wrench into the already blowing up engine(my brain)?
Just download it and look at the code. It doesn’t cost anything to look. Aside from all the reasons PDO is better, I think you will find it easier to use.
Can I assume you are using an editor with syntax highlighting?
Yes I use an editor with syntax highlighting. I haven’t written code in years but I did make it out of the dark ages, I think. ;D
After doing more reading than I care to admit to, I think I am going to stick with what I know, or I should say what I have a basic understanding of, mysqli. The pros don’t outweigh the cons on this one. PDO is slightly slower, though supports many different databases. Speed is a factor obviously and we own our servers so an chose the database. I do like that I can bind parameters better with PDO, but I have always had to keep them in order anyways so that isn’t a big deal.
OK, after spending some time reading over and researching the advice given I am going with prepared statements. With that said I am rewriting. So I started with a function to clean up the user input before doing my prepared statements.
A couple of notes.
- I know this will fail when there are form fields with names like foo[bar] or foo[] so I have skipped them and will deal with them later(after this part of the function passes scrutiny).
- “bio” is a user ad that allows basic html tags so I have skipped that.
- “files” will eventually be an img file upload so I have skipped that.
For S&G I counted all the user input fields… 33 and that doesn’t include the radio buttons! Hence the need for a good cover as many bases as possible function.
[php]function CleanFormData(){
array_walk_recursive($_POST, 'trim');
array_walk_recursive($_GET, 'trim');
foreach($_POST as $key => $value){
if($key == 'bio'){ continue; }
if($key == 'file'){ continue; }
if($key == 'role'){ continue; }
$_POST[$key] = is_array($key) ? $_POST[$key]: strip_tags($_POST[$key]);
}
return $_POST;
}[/php]
I do have a couple of questions though.
-
I am pretty sure I need to add htmlspecialchars() to this but in what order, strip tags(htmlspecialchars($POST[’’])) or htmlspecialchars(strip tags($POST[’’])).
-
I have skipped over “role” as it is a radio button but do I really need to as it will only return one choice.
-
Hardest last. I would like to use this on both POST and GET, I have an idea about how would like to do it but I am not sure it is possible.
As it is written:
[php]foreach($_POST as $key => $value){[/php]
How I would like to write it:
[php]foreach($_POST || $_GET as $key => $value){[/php] and the the return would be an if statement. If POST return $_POST, if GET return GET.
foreach($_REQUEST as $key => $value){
Not saying thats what you should do, but that will handle GET and POST
I think I know the answer, but tell me why I SHOULDN’T do this?
Because none of this makes any sense whatsoever.
First: As I already told you multiple times, the idea of mangling all user input (URL parameters, the request body, cookies) with some primitive “HTML filter” is just insane. This will lead to data corruption all over the place, and everybody who’s unfortunatey enough to work with the application will wonder what the hell is going on. Do you not understand how stupid this is?
Secondly, mangling [tt]$_REQUEST[/tt] has no effect on the original data source, be it [tt]$_POST[/tt], [tt]$_GET[/tt] or [tt]$_COOKIE[/tt]. So now you have a wild mixture of raw data and “filtered” data. In other words: The same user input will look and behave differently depenending on how exactly you happen to access it. That’s the very definition of bad software.
So for the love of god, get rid of this function and any other [tt]strip_whatever()[/tt] nonsense that may still be lurking in your code. I know you really love this stuff, but you need to let go. This project is already built on sand. If you don’t want it to crash and burn in the next couple of months, you need to start accepting basic programming knowledge.
Validate the input as you receive it, and escape it before you output the data. Really simple.
Because out of 34ish fields that this function covers only a few require any major validation, which is done in a separate function! The rest are optional fields. Why would I let something like a script tag slip through on these optional fields that I will just have to “fix” later, it just creates overhead. Out of the 34ish fields this function covers ONE, just ONE should have any kind of tags at all and I have skipped over it in the foreach loop it! I know what my user input should be, so why create overhead later by letting something through that has to be fixed that is stupid!
So to put it simply, I KNOW WHAT MY USER INPUT SHOULD BE and there should be NO TAGs in any $_POST variable with one exception and the foreach loop skips that one! Nothing to mangle as it shouldn’t be there in the first place and if it is they are up to something they shouldn’t be!
Who said anything about allowing HTML tags? What does the string “<3” from my example have to do with HTML tags? That’s a friggin’ emoticon, not a hacker attack from Russia, for heaven’s sake. The [tt]strip_tags()[/tt] function is way too primitive to recognize actual HTML tags. It’s a leftover from the early days of PHP when developers didn’t understand security and thought that destroying the user input would somehow help.
Why are you so obsessed with HTML tags, anyway? There are dozens of other attacks, you know? Are you saying you happily accept SQL injections, shell injections and whatnot as long as your HTML stays intact?
Or are you telling me that your application only accepts characters from the latin alphabet? Then good luck processing names like “Sinéad O’Connor” or any kind of e-mail address.
I repeat: This is plain stupid. Even if you were to disallow all non-latin input and tell 50% of the world population that they have “a wrong name”, you still wouldn’t silently mangle the input. You’d reject it. That’s how user interfaces work. When I post a message on this forum, the system either stores this exact message or prints an error. It doesn’t silently replace my message with something else just because I’ve happened to use an Irish name (how spooky!).
You said you want to learn. Then do it. Until now, all you’ve done is insist on some ill-conceived ideas from the 90s.
Go find another thread to troll… ???
Go find a job you’re qualified for.
Three people with a lot of experience have tried everything to help you, but you just cannot learn, because you’re too busy making excuses. No matter how many people tell you that you’re doing it wrong, you do it anway, because that’s how you did it in the 90s.
Good luck with your programming. You’ll need it.