Jacques1

Again: If this was actually possible, then PHP Freaks could make PayPal transactions on your behalf, read the inbox of your webmailer and whatnot. This of course is not possible. You somehow have this strange idea that the server can magically “tunnel” the user cookies to another site. It cannot. It can communicate with the client, and it can send its own requests to another site. That's it. If the server makes its own requests, then those of course contain the cookies of the server, not the cookies of some other person. It might be helpful if you read up how HTTP actually works. I think this will clear up the confusion.

The intermediate server does not use the forum session of the visitor. It cannot, because it doesn't have access to cookies for other sites. It gets a request from the visitor. And then it makes its own request to your forum. This is perfectly fine, because the server simply acts as yet another forum user with its own session. The visitor isn't involved in the second request in any way. When the reply shows up in the forum, it will say “server has written: ...” and not “visitor has written: ...”. Try it out. In fact, it's completely irrelevant that the server request was triggered by another request. This has no effect on the authorship of the request going to your forum. If your scenario actually worked like you think it does, this would break the entire Internet. You're basically saying that, for example, PHP Freaks could make requests to PayPal, Facebook or whatever using your current sessions on those sites. This of course is not possible. One site cannot access your cookies for other sites.

You don't understand. This request comes from your server, not the user. All you do is make your server send a request. Well, great. But that doesn't affect the user in any way, because it's not their request. For a CSRF attack, you need to trick the user's browser into sending the request. And this is not possible if every user has a secret token.

Hi, I think you misunderstand CSRF attacks. CSRF means that the attacker tricks another user into making a particular request. For example, if this forum was vulnerable to CSRF, I could set up a form which creates a certain reply. If you or your browser submit this form while you're logged in, the request will look like it's coming from you. In other words, you'll unknowingly write a reply with my content in it. To prevent this, a website will typically establish a shared secret between itself and the user: It generates a random token, stores it in the user's session and dynamically includes it in every form. Whenever the user makes a POST request, the server will check if the submitted token matches the one in the session. Only then will the request be accepted. Since other users generally don't have access to the user's token, they can no longer set up a “forged” form for this user. They simply don't know which token they need to include. Of course every user knows their own token. But they don't know the tokens of other users. That's the point. However, no CSRF protection is perfect. Every technique relies on the same-origin policy which says that one website cannot read the content of another website through the client's browser. This is what prevents an attacker from getting the user's token. If the attacker is able to bypass the same-origin policy, any CSRF protection is useless, because now they're very well able to fetch the token. A common way to break the same-origin policy is a cross-site scripting attack: If I'm able to inject JavaScript code into the target page, then I'm in the same origin and read any content I want. There are also more sophisticated attacks which exploit the DNS system.

I would neither use a regex nor load the entire file content into an array. E-mail regexes always suffer from the same two problems: They're wrong, and they're a (bad) reinvention of the wheel. The problem of validating e-mail addresses has been solved already: filter_var(). And iterating over the lines of a file can be done ad hoc with fgets(). This is more efficient and won't run into memory issues: <?php $list_path = '/path/to/file'; $list = fopen($list_path, 'r'); while ($line = fgets($list)) { if (!filter_var(trim($line), FILTER_VALIDATE_EMAIL)) { echo nl2br($line); } } fclose($list);

Hi, I don't see you using $a1 anywhere.

No, it doesn't. Either you're looking at the wrong variable, or the single quotes you're trying to replace aren't actually single quotes.

This has nothing to do with the parentheses. The ORDER BY clause simply has to come after the WHERE clause. Wherenever you're unsure about the syntax, the MySQL manual will help. Besides that, your code is wide open to SQL injection attacks, because you insert the raw user input straight into the query. Attackers can use this to manipulate the query and steal sensitive data or even take over the entire server. Always escape input before inserting it into a query. In modern programming, we actually avoid this problem altogether by using prepared statements. But this may not be supported by your CMS, depending on its age and quality.

Injecting the data straight into an inline script is a very, very bad idea and can lead to cross-site scripting vulnerabilities and bugs, which is why I recommended loading the data with Ajax . The json_encode() function is not for inserting data into a script element. It does not prevent the input from causing harm. For example, check out this attack. Fortunately, the PHP core developers are well aware that people notoriously misuse json_encode(), so they've at least prevented the most obvious attacks. But you can never be sure. It depends on your flavor of HTML and the flags you pass to json_encode() and the inner workings of the function. Do not rely on this.

Hi, the easiest and most secure solution is to make a PHP script which provides the data as JSON. In your JavaScript code which generates the chart, you'd then simply make an Ajax request to get the data from the PHP script.

You store passwords as plaintext? Seriously?

No, it's not difficult, but you'll need some time and motivation to learn the basics of MySQL and PDO. Do not rely on “tutorials”. Most of them are crap, and it's generally a bad idea to copy and paste code without understanding it.

No, I think you should utilize the API of the JSON feed. If the API is garbage and doesn't support any kind of limit, then, yes, you'll probably have to cache the data in your own database.

Besides that, your code is extremely insecure: You insert the raw user input into your query, which allows arbitrary visitors to perform an SQL injection attack. This can be used to steal sensitive data from your database or even take over the entire server. Since you store the passwords as plaintext (WTF?), this will be first target. You leak sensitive information about your database by outputting mysql_error() directly on the screen. Since you reuse the old running session without generating a new ID, your code is vulnerable to session fixation attacks. And of course all mysql_* functions are obsolete since more than 10 years and will be removed in one of the next PHP releases. Haven't you seen the big red warnings in the manual? I don't think you should upload this.

Well, if you think your code is just great and doesn't need to be changed, there's nothing we can do about that. All we can do is give advice to people who want to learn and improve. It doesn't matter how the rest of your code looks like. The parts you've posted are objectively bad and make no sense in any context. Whether you fix this or leave it at that is up to you.

It doesn't make much sense to load all data and then throw away the unwanted 90%. The page will still be slow, and you'll waste a lot of bandwidth. Check the API of the feed. It should allow you to load only partial content. Depending on how frequently the data changes, you should also consider throwing away the static pagination altogether. If new entries are added while a user browses the pages, then this user will either miss entries or see the same entries on different pages.

Hi, the code doesn't make much sense and is downright dangerous. Why on earth do you store the password hash in a cookie? The password must be protected, not thrown around. Your HMAC is far too long for the bcrypt algorithm (which I hope you're using). There's no error checking whatsoever. If crypt() returns an error string, you happily accept that as a valid hash. I strongly, strongly recommend that you keep away from home-made security and low-level functions like crypt(). This function in particular is a monster. I'm sure you've made plenty of mistakes when generating the original hash. If you have PHP 5.5, use the new password hashing API. If you don't have PHP 5.5 but at least 5.3.7, use the password_compat library. Do not try to implement this on your own. Your chance of success is very, very low.

Unfortunately, the people breaking into servers don't care about that. If you plan to upload your code at some point of time, it must be secure. Of course it takes time until you fully understand the various security issues. But I strongly recommend that you start thinking about this as early as possible and generally exercise common sense. The golden rule of security is: Do not trust user input. Every piece of data coming from the user must be regarded as harmful. So the last thing you want is include an unknown file just because the user told you so.

No offense, but this whole thing is just weird. You cannot use this approach. Do you really think it's a good idea to let the client choose which files should be included? Has it never occured to you that this might be a bit ... dangerous? Anybody is now able to read any file on your server as long as the webserver has access to it. Even worse, they can even execute any PHP script on your server or even from a remote location. This is the perfect way to get yourself hacked. I think it's best to start from scratch and do it in a sane way this time. If you need help with the planning, I'm sure we can help you.

If you know nothing about Ajax, how about learning it? jQuery has an excellent documentation. And of course there's Google with tons of additional explanations. I don't see the point of repeating the same things that have already been written down thousands of times and are just waiting for you to read them.

Well, I don't think trial-and-error will help. Since you're obviously new to PHP, you should slow down and do this step by step. Writing down 10 lines of code in one go only to find out that everything broken isn't very useful, because now you're stuck and need others to untangle the problem. Instead, grab a proper IDE like Netbeans and write one statement. Just one. The IDE will analyze it and tell you whether it's syntactically sound. If the statement is valid, you can go on with the next one. Otherwise you fix this one broken statement. From time to time, you should also check if the code is actually doing the right thing. The point is that you only have to debug one statement at a time. This is much easier than having to deal with 10 lines of broken code.

Um, what? Is this a question? A demonstration? A riddle? All I see is some badly broken PHP code which looks as if you've randomly pressed some keys. No parser will ever understand this. If you're trying to fix the code, it's probably best to start over, this time using actual PHP syntax. And you should start thinking about security. Raw PHP values inside HTML markup are a sure way of creating cross-site scripting vulnerabilities.

The parent element must have a non-static position as well. And you're missing a semicolon between the width and the height declaration.

Creating an instance and including it in different scripts also gives you only a single object, whereas autoloading gives you the class and lets you instantiate it as often as you want. Those are obviously two entirely different things. For example, let's say I have a File class which represents one file, and I want to use this class everywhere in my project. It wouldn't help me to create a single instance and pass it around. But auto-loading the class does make sense. Last but not least, I think you confuse simple static factory methods with The Factory Pattern. Those are two different things.

You should look up how autoloading actually works and what it does. I think this will eliminate the confusion. You cannot “instantiate a class and autoload it everywhere”. As I already said, autoloading can be used to load class definitions. You cannot load arbitrary scripts. I think you should forget about the Factory Pattern for now. It has absolutely nothing to do with the general problem of instantiating classes. It's an advanced design concept which you may use when you're familiar with the basics and try to improve your code. Resource sharing is yet another topic. I think you should postpone this as well. Before you jump into the advanced stuff, make sure you understand the basics (like autoloading).