Jacques1

Strangely enough, you do already use PDO but kept some mysql_* functions. If you fix this, the problem might actually go away.

So did you activate PDO exceptions again? Is your PHP error reporting on? What do you mean by “no output”? An empty array? The boolean false? We cannot magically fix your code just by looking at it. Since only you can run it, you must provide us with the relevant info.

Yeah. Good thing half of the forum population has turned out to be a group of highly skilled security experts who will foresee and fix any vulnerability in the future. Yesterday people couldn't write a single line of code without introducing two new SQL injection vulnerabilities. Now they know everything about secure systems.

shuffle($template); echo $template[0]; You should use a better name than $template, though.

If you're artificially restricted to shuffle(), you'd shuffle the array and then fetch the first element.

The code doesn't really make sense. You seem to have trouble understanding loops, which I already noticed in your previous thread. If you want a single picture, then don't use a loop. The point of a foreach loop is to iterate over all elements. This also means you cannot shuffle $temp, because that's a particular element (in this case a path string). Remove everything after the preg_grep() call and then select a random picture with array_rand().

Those are two unrelated security mechanisms. Parameterized queries prevent (most) SQL injection attacks, HTML-escaping is required to prevent cross-site scripting attacks. You need both.

You need to fix that immediately, not in the future. Cross-site scripting vulnerabilities are extremely dangerous and one of the first things any attacker will try to exploit.

PHP code runs on the server, cookies are managed by the client. That means deleting a cookie can only take effect after the code has been executed and the client has received the response. I recommend that you use the developer tools of your browser to see when cookies are set and deleted.

The most common security vulnerabilities are summarized in the OWASP Top 10 list. In my experience, PHP applications typically struggle with injection vulnerabilities. So if you use parameterized queries and rigorous HTML-escaping, that's definitely a good start. Besides the concrete defense mechanisms, it's important to develop a security-oriented way of thinking: Keep privileges at a minimum. Set up multiple layers of protection instead of relying on a single feature. Don't trust anything, unless it's absolutely necessary. Whitelisting is generally superior to blacklisting. Established, well-tested libraries are generally superior to homegrown implementations. Pádraic Brady does an excellent job at explaining this.

PDO is not a database abstraction layer, so you won't be able to simply plug in some NoSQL database. However, you can switch to a different SQL database system like PostgreSQL as long as you have the driver and rewrite the queries which are MySQL-specific.

I'm fairly sure he just meant that the same provider occurs multiple times in the result set. As in: Different categories can share one provider.

I don't see how the fact that you're running the server locally would automatically prevent any request size problems.

PDO is actually much easier to learn and use than MySQLi, so I'd give it a shot. If you still prefer MySQLi, that's fine. But be aware that it can become very tedious (e. g. fetching data from a prepared statement), and it creates a kind of “vendor lock-in”, because you won't be able to switch to a different database system.

The History API is the standard method for dynamically updating the URL with JavaScript. It's not obsolete in any way, and it's nothing special either.

Sorry, but what you're trying to do makes no sense. It's only natural for a public website to receive all kinds of requests from all kinds of agents. There's nothing scary about that, and the only way to prevent “unwanted” requests is to not have a public website. Assuming that all bots are evil while all human users are good doesn't make sense either. In fact, a human who actively tries to break into your site should scare you much more than some stupid bot scanning URLs. Needless to say that most bots are legitimate, useful tools which don't cause any harm whatsoever. If you're worried about the security of your website, then do something about that. Learn the basics of the security and make sure your code, your webserver and your operating system are safe. You need to do this anyway, so you might as well start now instead of trying to fight off bots. I'm sure somebody will recommend fail2ban, but I'd be careful about that. At best, this tool is a second line of defense which you apply at the very end. And in the worst case, it will give you a false sense of security and distract you from more important security measures.

No, it's not a refresh. If you open the developer tools of your browser, you'll see an Ajax request whenever new content needs to be loaded. Have you looked into the history API I mentioned above?

Are you sure that your webserver also allows big requests? What happens if you upload the file with a plain form?

DISTINCT, yes.

The manual suggests INT UNSIGNED for IPv4. Since IPv4 addresses cover only 32 bits, they fit into an 32-bit integer type. IPv6 addresses cover 128 bits, so they cannot possibly fit into any integer type. Hence my confusion as to what you actually want. It's unclear to me why you'd want to use LONG. This is a special compatibility type for exchanging code between MySQL and a non-MySQL database system. It's also a text type as opposed to a binary type, which means it uses a character encoding and sorts by a character collation. None of this makes sense for purely binary data like a raw IP address. So you'll want the binary type VARBINARY(16). This can store up to 128 bits.

If you want IPv6, then using an integer type makes no sense. You need a VARBINARY(16), and you have to pass the binary return value of inet_pton() directly to your database. Or use the MySQL functions instead of doing the conversion in PHP.

ip2long()

What exactly are you trying to do? The purpose of inet_pton() is to turn a human-readable IP address into a binary string. So making the string unprintable is pretty much the whole point. Appearently you want some human-readable format, so what would that look like?

Dumping raw variables into HTML markup is insecure and can lead to very nasty bugs. For example, if your color happens to contain a special character, you'll quickly run into syntax conflicts. And if an attacker is able to control the variables (e. g. by manipulating your database), this code can be used to perform a cross-site scripting attack. Always URL-encode and HTML-escape variables before inserting them into links: <?php function html_escape($raw_input, $encoding) { return htmlspecialchars($raw_input, ENT_QUOTES | ENT_SUBSTITUTE | ENT_HTML5, $encoding); } $image_url = 'http://www.brickbybricks.ca/php/images/'.rawurlencode($row['Color_Name']).'/'.rawurlencode($row['PartID']).'.gif'; echo '<td width="100"><div align="center"><img src="'.html_escape($image_url, 'UTF-8').'"></td>'; Note that using style attributes like width or align is heavily outdated. You should be using CSS. It's also bad practice to mix HTML markup into PHP code. Keep them separate: <?php // Your PHP code goes here ?> <!-- Your HTML markup goes here -->

I have absolutely no idea how this could possibly “work”. You're randomly selecting the role of a user, and if that user happens to be an admin, then you consider the current user an admin as well? So anybody can be an admin on your site if they're lucky? Shouldn't you be selecting the actual user that's currently logged in?