Jacques1

Your approach boils down to “security through obscurity”: Instead of using a proven solution, you try to irritate attackers with all kinds of “custom algorithms” and weird procedures, assuming that those are hard to find out. It has been demonstrated many times that this doesn't work. One of the PHP core developers actually put up a challenge where people had to guess custom hash algorithms from the hashes alone. From 15 algorithms, 14 were guessed correctly – in a short amount of time by people who did it just for fun. So I definitely would not try this challenge in a real application. Obscurity is actually dangerous, because “secret algorithms” are by definition neither properly reviewed nor tested. I've seen quite a lot of custom algorithms of all kinds, and almost all of them had fatal design flaws as well as implementation defects. Critical software must be peer-reviewed, ideally by thousands of experts all around the world. This has happened with the random number generator of your operating system. It has not happened and will never happen with your own algorithm. Good code doesn't have to be hidden. In fact, the best implementations I know are all publicy available on GitHub.

You must be kidding. So you're fine with leaking the personal data of your users “because it's already on Facebook”? Is that your attitude as a professional developer? Is that how you write applications? Also, you clearly don't know what an SQL injection vulnerability means. A single query can be used to take over the entire server, especially when the person responsible for the application thinks that “security isn't really such a big deal”.

A hash of the user ID and timestamp is a very bad “secret”. All of this data is public or easy to find out, which makes it trivial to brute-force the token. In fact, if the attacker himself requested the password reset, he knows the exact timestamp as well as the user ID. If that's your approach, you might as well allow anybody to take over any account. It's effectively the same. The token must be secret and impossible to guess. As I already said, it's equivalent to a password. And you wouldn't generate your password from a timestamp. This simply doesn't work in a web application where many concurrent processes access the same table at (almost) the same time. While you're still busy invalidating the current tokens and inserting a new one, there may be hundreds of new requests coming in. The result will be complete nonsense – or worse, a security vulnerability. Maybe this approach “works” with a handful of well-intentioned internal users, but it definitey doesn't work on the Internet.

Why should a value from a session automatically be SQL-safe? A session can contain anything. In fact, I would expect a username to contain single quotes, or else you'll have to ban the entire population of Ireland (O'Reilly, O’Neill, ...). Stop playing with SQL injection vulnerabilities and just use prepared statements for all dynamic input. At all times. No exception.

If you want a separate table, you should add a UNIQUE constraint to its user_id column and use INSERT ... ON DUPLICATE KEY UPDATE ... to insert a new token. If the user already has a token, MySQL will overwrite it instead of creating a new row (also known as an “upsert”). Any other approach will be either unreliable or very complex.

Binding the modules to physical folders isn't really a good idea, because it makes the architecture very inflexible. What if I want a large number of similar modules that share a lot of functionalities? It may not make sense to duplicate the entire folder structure for each one of them. What if I want virtual URLs that don't map to any physical classes at all? It think what you're looking for is a router which processes the URL and maps it to an arbitrary action. This allows you to separate the URL structure from the actual backend structure. It also solves the problem at hand, because instead of making PHP search the folder structure on every request, you register your modules and controllers once.

First off: You only store the token hashes, right? Tokens are equivalent to a password (at least the reset tokens), so they must not be stored as plaintext. Storing the token hashes in a separate table is in fact potentially dangerous, because it can lead to a situation where an attacker creates multiple reset requests for a victim account and then tries to guess the token. This is hopeless if you use a proper random number generator, but it can happen if there are weaknesses in the procedure. To be sure, a new token hash should always overwrite the previous hash. The easiest way to implement that is to store everying in the user table. Mixing the activation token with the reset token is also a bad idea. Sure, the verification process is somewhat similar, but the importance of the tokens is vastly different. While the activaction token isn't critical for security, knowing the reset token gives you full access to the account. So the tokens should be strictly separated. Do not reuse any fields in the table.

In theory, yes: You could use the session ID as a tempory API key; the API server would validate the session ID through an interface on the Drupal site (which simply yields a valid/invalid reply). The Drupal site could issue a client-side API session which is protected with a message authentication code or cryptographic signature. Maybe OpenID or OAuth work as well. Public-key authentication (e. g. TLS with client certificates) is another theoretical option. In practice, not really.

No need to get butthurt over a few simple facts.

Who controls the outermost server? Why can't you have one API key per client? And who are the clients? Human users? If so, what kind of users? Arbitrary people on the Internet? A small group of experts? Or are you talking about automated clients? If so, where are they installed?

I understand the idea, but I'm afraid it doesn't work in practice. Pretty much the only errors you'll get from mail() are related to the mail system itself. And if such a problem occurs, you won't get your alert mails either. mail() is a very primitive function. You seem to think that it thorougly validates the input and tells you exactly what's wrong, but that's not the case. Use normal error logging like everybody else. Or install a global error handler which checks the entire script and sends you a summary of errors. You should also replace the old mail() function with a proper library like PHPMailer to get more detailed messages (as well as more security, more usability, more efficiency).

The log-in script is a joke. This method alone is a clear sign that the author has no idea what he's doing: function generate_password_hash($password, $user_code) { $hash[] = md5($password); $hash[] = md5($password . $user_code); $hash[] = md5($password) . sha1($user_code . $password) . md5(md5($password)); $hash[] = sha1($password . $user_code . $password); $hash[] = md5($hash[3] . $hash[0] . $hash[1] . $hash[2] . sha1($hash[3] . $hash[2])); $hash[] = sha1($hash[0] . $hash[1] . $hash[2] . $hash[3]) . md5($hash[4] . $hash[4]) . sha1($user_code); return sha1($hash[0] . $hash[1] . $hash[2] . $hash[3] . $hash[4] . $hash[5] . md5($user_code)); } What on earth is this supposed to do? It looks as if a cat jumped on the keyboard. The code is also close to 10 years old, which is a very, very long time in web programming, especially in the security field. A lot has changed since 2007. It's generally a bad idea to download random code from the Internet and put it on your server. Most of it is crap put together by amateurs, lots of it is actually malicious and will open your application to all kinds of attacks. Either learn and write your own code. Or look for a credible library. Credible means: It's actively maintained by professional programmers who understand security. There must be versions, updates and bugfixes, not just some lone .zip file. It should be under version control (e. g. a GitHub project) so that you can keep track of code changes. It must use state-of-the-art algorithms like bcrypt (which is available through the built-in password_hash() function). To be honest, I'm not aware of any such project outside of big frameworks.

And your question is what exactly? It's obvious that you cannot pass raw request parameters to a function that expects numeric types. So? Why would you want that? There should be a component in your application which validates the raw input, converts it when necessary and then passes the converted data on to other methods and functions. You shouldn't have $_GET and $_POST all over the place, anyway.

What kind of error messages do you even expect? If you're talking about bugs, you should fix them ahead of time with tests. If this is about mail-related issues on your own server, then trying to send out an error mail doesn't make a lot of sense. If it's about mail-related issue on the target server, then PHP's mail() function doesn't cover those.

See the link in my reply. You can literally copy and paste the code.

Like kicken already said, PHP automatically closes the connection. Closing it manually a few microseconds earlier serves no purpose. While we're at it: Remove the last “?>” tag as well. It's not only useless but harmful. The closing tag makes PHP switch back into output mode, so if there's just one space after the tag, PHP will in fact send it to the client. And as you probably know, once there's output, it's no longer possible to start a session, issue a cookie or set an HTTP header. This is a huge problem when an included script accidentally starts output (like the already mentioned space) and blocks the entire main script. So just get rid of the tag. It's only needed when you actually want to write HTML markup after the PHP code.

Again: An HTML document cannot have multiple elements with the same ID. This violates both the HTML specification and common logic. ID means “identifier”, so by definition it uniquely references a single entity. So the real question is: Why is your data source fudged up? Where does the broken HTML come from? Did you generate this? Fix the data source, and the rest will be easy.

This isn't about one query, it's about an entire database library. You cannot randomly insert a PDO or mysqli method call in the middle of your code. You choose one library, and then all database operations now and in the future have to be implemented with that library. You may even have to rewrite large parts of your current code. Forget about the single value stuff. This is about all of your queries.

Um, what? You said you want to get the href value of exactly one a element with the ID "streams". Your code does that. Now you're talking about more than one element? What are those other elements you want to fetch? If you have more than one element with the same ID, that's wrong. The ID must be unique accross the entire document.

I said what I said. Now you need to read and understand it. I know you're in a hurry, and reading longer texts is difficult in the era of 140-character Tweets. But if you want to write any code whatsoever, you have to be able to absorb information. Programming isn't copy-and-paste.

What you don't seem to understand is that accessing a database requires a complete library. This isn't just one line of code which you can copy and paste. You have to establish a connection, execute a query (or in your case a prepared statement) and ultimately fetch data from the result set. So the first step is to choose a library. The mysql_* functions you were using previously are hopelessly outdated and have already been removed from the current PHP version. Nowadays were're using PDO or mysqli. PDO is a good choice. Now you need to learn PDO. We can't do that for you. You need to actually read and understand the tutorial referenced by benanamen.

I suggest you start with the basics before jumping to any special features. There seems to be a lot of confusion here. You said you used mysqli, you've actually used the old ext/mysql extension, and now you've appearently switched to PDO. If you want to go with PDO, learn how to establish a connection first.

There is no special mysqli method for fetching a single value. You fetch the entire row like with any other query. If you want more specific advice, show your current code.

So you have fixed the syntax errors and made sure that $xpath is actually defined? What exactly is the problem now? I'm talking about specific error messages or symptoms, not "it doesn't work".

Writing syntactically valid PHP code might be a good start. This isn't valid (note the closing bracket): $streams_url = $xpath->query("//span[@id='streams'"]); This isn't either: >?