IllegalPigeon

Notice the "/s". I was being sarcastic. There was no need for the strip_tags() in the first instance. G7 posted a snippet saying "if(strip_tags($_GET['logout']) == 'true')". Well, if "$_GET['logout']" is anything OTHER than "true", it will fail. If $_GET['logout'] = <script>alert("xss")</script>, that does not equal "true", so it'll fail. G7's code would ALLOW for something like this, though: $_GET['logout'] = '<script>true</script>'; because after the tags have been stripped, it will equal true. There's just no need for it at all. if(isset($var) && $var == 'true') is fine. By adding strip_tags() to it, you're not adding an extra layer of security or anything at all for that matter.

Yeah, should be: if(isset(mysql_real_escape_string($_GET['logout'])) & htmlentities(htmlspecialchars(url_encode(strip_tags($_GET['logout'])))) == 'true') { } /s

Just looking over some of the logs. Thank you to those of you that have been trying to access typical McCode file names, it helps remind me that this is custom built because sometimes I forget. I assure you, file names like "loggedin.php" and "register.php" will not work.

Ah, but, you haven't seen the rest of the page yet ;)

Are you leaving the "operation-x" watermarks in? I think they look cool.

It depends largely on your CSS, too. Also, why is your menu you a table? Did you know your "awards" links to: http://www.jquery2dotnet.com? lol

Have you tried using Chrome's debugging tools to see if you're getting any conflicts?

Okay guys, er, this pains me to admit... I was doing some testing and realised something. The way I was collecting/storing IP addresses, to check if a user had already pre-registered, was wrong. It was actually storing the IP from Varnish, ergo, most people had the same IP. Apologies if you were redirected! I've nullified all of the IP's that were in the database as they are incorrect. The system is now collecting the right IP addresses and the problem should be resolved!

procedural!! Woooooo

And just for arguments sake, the same code ran on some static content. Let's load a loop of 10,000 (corrected execution time) My way, the proper way: 0.00055985 Your way, the wrong way: 0.00066395 Now I have a lovely fast loop, that I can extend and is done in true "OOP" style, and adhere's to PSR standards, how delightful! Edit: I just want to point out, I do not care about the load times here, even if the results are what I wanted. I'm just pointing out that having a single function inside of a "globals" file isn't PSR standard or OOP AND often times, it's still slower. You're either coding something in OOP style or you're not. Pick one, it will make your life easier.

It *is* 100% true. You seem to be confused by "less lines" > "number of files". Which isn't the OOP way, which leads me to believe you have little understanding of OOP itself. You're more than welcome to try and prove me wrong, though. I applaud you to try. These examples were run from within a project I'm currently working on, where we use PSR-4 autoloading to load my model. I just created a "check_user" function that runs a single database query, using PDO. Total Execution Time: 6.83466 I load my model, in the correct PSR standard way, which has a "user" class, we instantiate the class and call a static method to return the query: Total Execution Time: 4.33912 So not sure what planet you're living on. Now, I've got code that executes quicker AND it's easier to read and extend. What a fabulous result.

Are we talking about the red box you get when you error? Is it still too big? Is it still the entire screen? It shouldn't be, because I said to [MENTION=71662]CaptainQuack[/MENTION] "We need to fix that", and he said "Yeah, ok". Should have been fixed, right? So I trust that it is indeed fixed?

Hey, that's my name.

It doesn't matter about the lines of code, that's what OOP is and functionally speaking, it's 100x's better. Infact, if you nail your autoloader, calling a static method is quicker than calling a function you've loosely named in a "globals.php" file. Unless, of course, all you're returning is a hard-coded string. I'd rather use a full OOP implementation than half of one. What happens if I wanted to extend the functionality of "User_get_info" without having to edit the globals file, which I assume is "core"? I can't extend it or build a layer on top.

Doesn't look very "OO" to me. Looks like you've created a function called "User_get_info" and that's it. But, that's based off of your current example. Preferably, you'd want to instantiate a new user model/class, and then fetch the data using a function. Like I said, though, this is 16 lines of code. Hard to tell what you're really doing.

No worries. These things happen! That's why I like using things like Sass and Gulp. You get compile errors if stuff like this happens!

Yeah, Dayo hit the nail on the head. loggedin3.css line 2499 #ward { background: url(../images/ward.png) no-repeat center center; height: 500px; should be #ward { background: url(../images/ward.png) no-repeat center center; height: 500px; } loggedin2.css line 2496 #ward { background: url(../images/ward.png) no-repeat center center; height: 500px; should be #ward { background: url(../images/ward.png) no-repeat center center; height: 500px; }

Do you have a link to your site? Will be easier to debug.

So...where's the public_html reference?

But...it doesn't delete the public_html folder. Where do you see public_html referenced there?

Worked for me! Thanks, Quack. You're the best. People could learn a lot from you.

Just tested this on a clients website, as I needed to secure it. It worked! The DDoS attacks they were experiencing completely stopped and my user data, in which I stored passwords in plain text, is also secure! Cheers bro :D

Okay, so please, show me how you did a CSRF attack. I'd love to see. Don't you start.

You learn to code. There's no quick fix. You don't add a line of code in your head and it's magically done. Firstly, I suggest you look into PDO. Prepared statements will help you drastically. As for "how could someone hack it?". Quite easily, I've seen the code. You know that SQL Injection and Shells aren't the only two methods use to hack websites? XSS? CSRF? Remote code execution? Session manipulation/a list of other things to manipulate? Need a go on?

You're obsessed with removing MRES(). They were simply being used incorrectly. Using a function that escapes strings on a number is improper usage, as is true for quoting numbers as if they were strings. Do tell what "SQL Injection" you used. Or what shell you used? Let me guess, you took a URL that looked like; "www.game.com/item.php?id=1" and made it "www.game.com/item.php?id='" or something similar? In which case, fine, your game is secure against script kiddies and 99% of this forum that think they are brilliant hackers and programmers. You're not protected against literally a plethora of vulnerabilities. I don't even need to see your game to tell you that, I've seen you posting code snippets and I assure you, your game is not secure.