requinix

Sessions are cleaned up periodically by PHP or the system (depending on the setup). Until then the session is always accessible by anyone who has the session ID and at any time.

No. You shouldn't really be doing that at all. Autoloading only happens when you try to reference a class (like instantiating it or something else I forget) and if the class's file hasn't been included it. If you require() the file then try to instantiate it the autoloading stuff won't fire - it's already been loaded. Your class files should just have the class definition with very few exceptions. Make an autoloader using spl_register_autoload() (__autoload() is deprecated) that includes the appropriate file when the class is requested. Then every time you need the class you try to use it. And if you only want one instance of a class around then you should be using a Singleton, not a pre-instantiated class.

I've never heard the term "design method", but a design pattern is basically just a way of solving a fairly common problem. For example, have you ever wanted to make a class that stores a bunch of data so it's all available in one place? There's a design pattern for that. Ever wanted to make sure that only one instance of a class exists and others can't be created? There's a design pattern for that too. Ever seen a really complicated class and felt like making another class that's much easier to use? Guess what? Google it. There's a ton of information out there on the subject.

Thanks for the heads-up thorpe. brooksh, if you didn't see, the code is not malicious. It's quite simple and could not cause the 100% usage you're seeing.

Great. Then let them enter whatever they want and you htmlentities() or htmlspecialchars() it before you display it anywhere. (And yes, I realize there is no "onhover" event. I wasn't trying to be precise )

It's complicated. Can you post the whole file unedited?

The fact of the matter is that it can be very difficult to sanitize arbitrary HTML. strip_tags() will remove tags you don't want but it won't do anything about attributes; even if you allowed only tags someone could use You could use regular expressions to deal with most of this by making sure there aren't any invalid tags #?b[^>]+># (if this matches then there's a tag with something inside it), but all you're accomplishing is allowing for BBCode tags that use s instead of []s. Which isn't bad, it's just that you've gone full circle. Either way you need to do something with the comment form if you want to allow some kind of markup.

Besides finding some library that does the session+database stuff already, not really.

Compare the output of phpinfo() on the two hosts. Normally these white page issues are because of syntax errors, and if it's happening after a migration then it's quite likely that the PHP versions and/or configurations don't match.

They don't disallow it - they can't, there's no way to. But they can tell you that using the normal session is pointless, and it is for the reasons they stated. Except you can use sessions in a database instead. Since all the cloud servers can access the database they can also share the session information. Normal sessions are handled with files and PHP just reads and writes variables and values in them. So instead of files you configure PHP (by writing code) to use a database instead. The rest of the session stuff with $_SESSION and session_start() still applies without any changes, but behind the scenes PHP goes through some custom code for loading and saving.

Don't let them post HTML and instead allow BBCode (or something similar). People can still enter links and images, format with bold and underlines, change font size and color... It's a different yet very similar syntax, but it's so common nowadays that the people who do know HTML 99% likely know BBCode as well.

Considering the flak we gave you for the other one, I'll try to be nicer. It's possible if you use file locking but know that there are situations where it will not work. Basically you open the file, lock it so that other processes can't read from it, do your work, then unlock and close. File locking flock file_put_contents can lock starting with PHP 5.1 However this is another one of those things that you really should fix, especially given that you'd have to implement the locking logic everywhere you read from or write to a file anyways. Even giving you some credit for dealing with the other problem isn't enough to deal with this particular issue. It will cause problems. Databases are much easier to deal with and are definitely worth the additional time to learn and use and you don't have to worry about any of this locking nonsense.

Bad news. You should be storing all this stuff in a database, not flat files (as it's called).

So I could post, say, <br /> malicious_code(document.cookie, document.location);<br /> where malicious.js is, well, malicious. You wouldn't mind that?

All those hash=, responseText=, and so on are the keys. There's no intermediary array or something. Assuming they POST it, $_POST["hash"] $_POST["responseText"] // etc The $fields stuff should always be there but $Address ones might not be. There's also the END that I'm sure you'll want to ignore. If you still can't get to it, dump out $_POST (or $_GET) with var_dump() or print_r() and see exactly what you're getting. (that's assuming the rest of their stuff works... those rtrim()s they have cast some doubt)

Throw in a DISTINCT. SELECT COUNT(DISTINCT the column about the trophy) as num1... Side note: when doing stuff with strings in PHP, always use quotes. Field names from SQL queries count. $total_trophies["num1"]

Then... you need to change the query? With a name like "id" I would have expected it to be unique for the entire table, but I guess that's not the case. Does it have the same value for the same kind of trophy? So all Trophy 1s have one value while all Trophy 2s have a different one value?

Yep.

It "inherits". The reality is that PHP keeps executing from where it left off - nothing changes, nothing resets, nothing goes away. It's basically the same as copy/pasting the code from script_2 into script_1.

Do you want to allow people to enter HTML?

I didn't say you can hide the source code. That's not possible. But you can hide the actual location of the image. I'm not going to tell you how because: What you have now is bad. It needs to change because it is bad. Doing anything other than fixing it is also bad. The fact that it may take a lot of work doesn't matter - it needs to change.

Like I said in the other thread :-\ it's possible to hide the location of the image but you still need to redo the system.

Yes, but you still need to redo it.

And that there is the downside to getting these kinds of script on the Internet: iffy support. You should get a programmer to go through everything. That's a fact but perhaps not a necessity. Do you know anything about PHP or MySQL? Is there a phpMyAdmin you can use to access the database (or something similar)?

First, understand that mysqli doesn't really do a whole lot of work. Everything comes from the MySQL C library. So most of the answers to your questions are along the lines of "the code calls the appropriate function from MySQL's C library". Besides that, 1. The query is prepared (which involves it being parsed for validity), you bind a value to the one parameter, the query and bound values are sent to the MySQL server, the server does whatever it does, and handle to the result gets passed back to the library. Your code then instructs that the resultset gets stored in memory, you bind variables to columns, each row is (re)read, and the variables are updated. mysqli itself only does a bit of that. 2. In memory. 3. It binds stuff internally in pretty much the same way the PHP code binds stuff. It does not set values (which it does via references) until you begin (re)reading the resultset. 4. The code calls the appropriate function from MySQL's C library and does some other stuff.