Jacques1

No offense, adam_bray, but if you hand out complete code to other people, at least make sure it's good. This definitely isn't. The mysql_* functions are obsolete since more than a decade and will be removed in one of the next PHP releases. Nowadays, we use PDO. This or die(mysql_error()) stuff makes absolutely no sense and is actually a security vulnerability. Why would you want your users to see the exact MySQL error message with all information about your internal database structure? The whole code structure is very cumbersome and doesn't make a lot of sense. Besides that, how exactly does it help Matthijs to give him yet another piece of code to copy and paste? As far as I can tell, his GitHub account is already full of those scripts, and yet he struggles with the basics of PHP. Wouldn't it be much better to encourage people to actually learn the language and write their own code? I'm sorry for being harsh, but I think this copypasta mania is the cancer that's killing PHP. It doesn't help anybody to just blindly duplicate bad code. You learn absolutely nothing from it.

Using the date functions of PHP isn't challenging enough for you guys, I guess? <?php // check the manual for the acceptable date formats $birthdate = '1993-05-06'; if (strtotime($birthdate) <= strtotime('21 years ago')) { echo 'You are indeed 21.'; } else { echo 'You are not old enough.'; }

The URL has a parameter which contains the username, right? For example: https://yoursite.com/profile.php?name=matthijs110 There's a parameter called “name”, and the parameter has the value “matthijs110”. This is the username you're looking for. So you take the “name” parameter and search the users table for this exact username.

You do not know what? You obviously do know how to access GET/POST data, query the database and render an HTML page. And that's all you need for this task. So just start and see how far you get.

I already told you: You search the users table in your database for the name from the URL. If the name exists, you fetch the data and render your HTML from it. If the name does not exist, you render an error page and emit a 404 response. If you want a more concrete answer, show us the current code.

Sorry, but what you're saying doesn't make much sense. Maybe it's just the wording, maybe there's a fundamental misunderstanding regarding PHP. You do not “make URLs” (whatever that means). A visitor requests a certain URL, and then you act upon it. For example, a visitor might request https://yourdomain.com/profile/foobar. The first step is that your webserver internally rewrites the URL to https://yourdomain.com/profile.php?name=foobar and calls the profile.php script. Then this script looks up the name in the database. If the user exists, you render the profile from the data. If the user does not exist, you respond with a 404 message saying something like “Sorry, this user does not exist”. Of course you can also provide a list of all current users or something like that. But you do not literally “make links”.

I think the handling of booleans also needs some practice. What exactly is if ($some_var == true) supposed to do? Are you afraid that the variable itself somehow isn't true enough and needs some extra trueness? Then why stop there? Why not: if (((($some_var == true) == true) == true) == true) Maybe it's even truer now. Personally, however, I'd simply test the value: if ($some_var)

Looks like this is easier said than done.

I have absolutely no idea why you're trying to use serialize(). What do you expect this function to do? If you check the manual, you'll see that it creates a technical string representation of a value to be stored for later deserialization. That's not exactly helpful in your case. I also don't get why you throw away the first cURL instance and create a new one. What's wrong with the first one? Regarding multiple URLs, you want curl_multi_init().

If you want to allow limited use of HTML, you need much more sophisticated tools and a lot of knowledge about different attacks. Unless you really, really want people to post clickable links and are willing to invest a lot of time in this particular feature, you should keep away from this. It's not worth the trouble. Just have people post their links as plaintext. Dealing with HTML in a secure way is already a major task and requires a fully-featured library like HTML Purifier. In addition to this, links are particularly nasty, because they can be used for all kinds of attacks. For example, links can execute JavaScript code: <a href="javascript:alert('XSS')">Click me!</a> And links can render complete pages which execute JavaScript: <a href="data:text/html;charset=utf-8;base64,PHNjcmlwdD5hbGVydCgnWFNTJyk8L3NjcmlwdD4=">Click me!</a> And of course links can point to malicious websites. It's not worth the trouble.

Hi, please forget about this strip_tags() garbage.. Not sure where you dug this function out, but it never made any sense whatsoever. What it does is mangle the input and delete everything which somehow looks like an HTML tag. For example, if a user chooses the name “I <3 PHP”, you end up with “I ”. Why would you want that? The strip_tags() function is one of those infamous brainfarts of the PHP core developers. They look at a problem (in this case cross-site scripting vulnerabilities), fail to understand it and consequently add some completely useless “feature” to the PHP core. And then generations of PHP newbies run around with this crap instead of using an appropriate solution. To prevent cross-site scripting attacks, use htmlspecialchars() right when you insert the value into the HTML document. Do not mangle the user input. This is not only pointless, it also kills usability. Would you want to work with an application which randomly breaks your input? I wouldn't.

Hi, we can speculate all day long about what the array might contain. But it would be much easier if you simply inspected it: var_dump($image); What does that say?

I understand the concept of session fixation attacks. The problem is that I don't see how “Strict Sessions” are supposed to prevent this. An attacker doesn't have to make up their own ID. They can simply obtain a fresh one from the application and use that. This will pass all checks of the “Strict Sessions” feature. At the same time, session fixation can easily be stopped by calling session_regenerate_id() in the login procedure. Even if an attacker has managed to set a custom session ID in the victim's browser, now the session has a new ID.

Hi, you'll be surprised to hear that Apache has this tool already, and it happens to be called htpasswd. Note that you must use the bcrypt algorithm. All other algorithms are hopelessly outdated and can be broken in a matter of minutes. Also note that this is hashing, not “encryption”. Those are two entirely different things.

I'm sure it gives you results. The thing is that it doesn't give you an associative array. If you're saying that you've managed to make mysql_fetch_row() return an associative array, that would indeed be interesting.

Hi, PHP 5.5 has introduced a (little-known) feature called “Strict Sessions” which is supposed to prevent session fixation. It will reject any session ID for which there's no corresponding session file, so it's no longer possible for users to have PHP adopt their own ID. For a detailed description, see the RFC. Does anybody have any idea how this approach is useful? The article goes into a lengthy discussion of how it's possible for an attacker to override the native session cookie with a custom cookie. No doubt about that. But how is that relevant? People can override my session ID all day long. The only thing I do not want is that PHP stores my user ID in one of those sessions in the login procedure. And this can easily be prevented with session_regenerate_id(). Furthermore, “Strict Sessions” obviously do not prevent an attacker from obtaining a valid session ID from the application and using that for a session fixation attack. There's simply no need to make up an ID. Am I missing something? Or is this just yet another “genius security feature” along the lines of Magic Quotes?

Just read the function description and skip the user comments: That looks pretty straightforward to me: One returns a numerical array (with the keys 0, 1, 2, ...), the other one returns an associative array (with the column names as the keys). If you want to access the values by the column names, you need an associative array. If you want to access the values by the column indexes (which should be rare), you need a numerical array. I don't know what you mean by “it is working on other pages”, but those two functions always work the same.

Guys, please escape your variables before inserting them into the HTML markup. We've had enough cross-site scripting vulnerabilities. I also see absolutely no reason why you should use a URL parameter. Since you're dealing with a form, a hidden parameter is the correct solution. The reason why your code doesn't work is because you're trying to have a PHP code block within a PHP code block. This is not possible. So a corrected and sanitized version would look like this: <?php // Do not forget the escaping! echo '<input type="hidden" name="shoppingid" value="' . html_escape($_POST['shop'], 'UTF-8') . '">'; function html_escape($raw_string, $encoding) { return htmlspecialchars($raw_string, ENT_QUOTES, $encoding); }

Hi, please get rid of this garbage class and stop stealing random bullshit from the internet. I'm sorry for being so harsh, but this really is the cancer of PHP. Why don't you write you own code? Start with a blank file and write down your own ideas while you search the PHP manual for the right functions. Yes, this takes time, and your first scripts won't be very good. But they will be your scripts, and you'll learn from them. There's nothing you could learn from that class you've copypasted. Whoever wrote it doesn't know anything whatsoever about PHP or security or good code. It's just an incredibly naïve attempt of implementing “Magic Quotes on steroids” or something like that. You should actually look at the code, it's pretty funny: private function secureSuperGlobalGET(&$value, $key) { $_GET[$key] = htmlspecialchars(stripslashes($_GET[$key])); $_GET[$key] = str_ireplace("<script", "<blocked", $_GET[$key]); $_GET[$key] = mysql_escape_string($_GET[$key]); $_GET[$key] = preg_replace('/DROP TABLE | TRUNCATE TABLE |EXECUTE /i', '', $_GET[$key]); return $_GET[$key]; } What kind of drugs does it take to think this is a good idea?

No, but I've been using PHP long enough to know that nonexistent array keys trigger a notice – that is, unless you're suppressing notices. I think you confuse your own error handling (the die() stuff) with the internal error handling of PHP. Those are two entirely different things. Of course your own error messages do work. But you've forgotten to turn the internal errors on. That's the ones I'm talking about. You can't just append an “i” to all mysql_* functions. That may seem to be the easy way out, but it doesn't work. The MySQLi extension is very different from the old MySQL extension, so you have to actually rewrite your code. Actually, I strongly advice against MySQLi. As the previous posters have already pointed out, you should be using PDO. It's much more powerful and convenient. You need to leave out the "<table>." part. The name of the columns is what comes after the dot.

It would actually have been enough to turn the error reporting on: Go to the php.ini and set display_errors to On and error_reporting to -1. Always make sure that the error reporting is on and up when you write code. PHP will warn you about many errors, including invalid indexes. But of course you'll miss this when you suppress the messages. Yes, and switchting to PDO is definitely a good idea.

Your if statement lacks a closing parenthesis. But the actual problem is that you write code with all error messages turned off. Go to the php.ini and set display_errors to On and error_reporting to -1.

Hi, is there any reason why you want to load the data into an array? Parsing the entire CSV an every single request is pretty much the most cumbersome and inefficient solution you can get, especially when you're dealing with more data than in your example. It would make much more sense to import the data into your database where it belongs. Then you can actually query it and fetch specific information.

I think the problem is that you're missing the whole point of OOP: It's about objects (hence the name). You don't seem to care about objects at all. All you do is (mis)use classes as a way to group functions and variables. That's not OOP. It's modular programming, a variant of procedural programming. I have the feeling that you're using OOP for the wrong reasons. Maybe someone has told you that procedural code is outdated/bad/uncool/whatever, and now you're trying to make everything look like OOP. That doesn't make much sense. If you have good procedural code, by all means, keep it. It's not like adding a bunch of classes would somehow magically improve code quality. To the contrary. Yes, OOP can be useful in some cases. But you should treat it as a tool to achieve a specific goal, not a fetish. Regarding your session class, I don't see that goal. This again is just a collection of functions. There are no objects with their own state, just a class. So why not have real functions?

Well, if you make everything static and never instantiate the class, when do you expect the constructor to be called? The whole purpose of the constructor is to initialize a newly created object. No object, no constructor. Apart from that, a class which only consists of static members is a typical case of procedural code masquerading as OOP.