Jacques1

A binary data type is wrong in this case, because all crypt-based hashes are ASCII-encoded strings, not raw bytes. If you (ab)use BINARY or VARBINARY for the hashes, you lose type safety and may end up with garbage data. A raw byte sequence is entirely unrestricted, but ASCII only ranges from 0x00 to 0x7F. So while your database will accept any input, you may later find out that the data you've stored isn't even valid (due to a bug, a confused admin or whatever). Always choose the correct type for the content so that the database system can do its job. Don't try any hacks to optimize performance. Even if one of them actually works out and saves you some microseconds, you risk the integrity of your data. That's not worth it. In this particular case, the performance argument makes even less sense: Password hashing is slow by design, so performance is not a concern here. The last thing you want is a bug in the password check, so any kind of hack is out of the question. The correct type for bcrypt is CHAR(60). If the algorithm is unspecified, use TEXT or VARCHAR with a sufficient length (whatever that may be).

Then I have no idea why you told us that it's impossible to make “Ajax requests” with cURL. Was it just a brainfart?

No offense, jazzman, but I think you're very confused. The communication between the client and the server consists of exchanging IP packets (which contain the HTTP messages). The server doesn't know anything about the client except the IP address. It has absolutely no idea what the client did to generate the data: Could be Ajax, could be a “classical” request, could be cURL or any other tool. Hell, the client could have manually typed in the bytes with their keyboard. We don't know, and we cannot find out. All we know is that a particular IP address has sent us an HTTP request. For the server, there's no such thing as “Ajax”. This is a client-side technique, and you have no way to detect or enforce it. Think of the client as a black box: Data goes in, data goes out, but what happens inside the box is completely unknown. Is it a human user or a bot? Do they use a browser? If they use a browser, do they have JavaScript enabled? We have no idea.

An Ajax request is an HTTP request. Have you never opened the “network” tab of your browser to see what's going on behind the scenes? It doesn't matter if the request comes from JavaScript or cURL or whatever. You might as well write it down by hand. The server doesn't know and doesn't care. It's all just a bunch of bytes in a bunch of IP packets.

Like I explained in #4: One script for logging in and one script which checks the log-in status. The log-in script can be as simple as <?php session_start(); if ($_POST['name'] == 'foo' && $_POST['password'] == 'bar') { $_SESSION['logged_in'] = true; echo 'Log-in successful'; } else { echo 'Log-in failed'; } The point is that you should test and fix your cURL code before you go to the next step of using it on an actual site. It's not helpful to end up with some blank page and no idea what might be wrong. Um, what? You do realize that the end result is always an HTTP request, right? Or did you think JavaScript performs some kind of magic?

You're not sending the cookies anywhere. And the entire log-in procedure looked more complicated to me than just sending the name and password to the site. Like I said, do this step by step. Create a simple test script on your PC and try out cURL in a controlled environment before you jump to some live site.

Search for something like “php curl login”. On the first page, there's already a Stack Overflow thread where this problem is discussed in great detail and with many examples. The relevant cURL options are CURLOPT_POST and CURLOPT_POSTFIELDS for making the initial POST request. You'll also need CURLOPT_COOKIEJAR for writing the session cookie to a file and CURLOPT_COOKIEFILE for reading the cookie from that file.

There are literally hundreds of examples on Google. Why don't you look for them yourself and come back when you have a concrete question? To get familar with the authentication procedure, it might be a good idea to set up a simple test application on your localhost. Make one log-in script and one script which requires a valid session. See if you can post your credentials to the log-in script and store the session cookie you get back. If that works, see if you can access the protected script with the stored cookie.

This site uses a cookie-based session system. If you inspect the cookies in your browser, you'll see one called “ASP.NET_SessionId”. This obviously carries the session ID. So you need to send your credentials to their ASP.NET application, store the session cookie and then send it along with every request. This is way beyond the capablities of file_get_contents(). Use the cURL library instead. Note that you'll need a basic understanding of how HTTP works.

I don't think this is good code. The general rule is that a file either contains declarations or has side-effects, not both. This is explictly specified in the PSR standards. Of course you're free to violate the rules. For example, many people do have function declarations within regular scripts. But a complete class? That's just spaghetti code and very confusing. He wants to restrict properties to one script. So other classes within the same file do have access, but not the classes in other files.

An internal modifier doesn't make a lot of sense in PHP, because you generally have only one class definition per file. In fact, auto-loaders expect this structure. At best, you might come up with a scenario where you have an auxiliary class which is only supposed to be used by another class in the same file. In that case, the modifier theoretically makes sense. But it would be very confusing and against all common practice. PHP simply isn't C#, and it won't become that in the near future.

What? Do you even know what that means?

See the PHP site. There are quite a lot of security improvements: When you download a resource via HTTPS using file_get_contents(), PHP now actually checks the certificate. Before, certificate validation was turned off by default, which is of course a joke and left a lot of applications wide open to man-in-the-middle attacks. The Mcrypt extension no longer accepts incorrect keys or missing initialization vectors. The function hash_equals() allows you to compare secret strings without leaking their content through time differences.

I strongly recommend that you do not upload your application yet. It doesn't matter if it's widely distributed or not. As soon as it's online, anybody can access it. In fact, attackers love small, unprotected sites, because they're an easy target. SQL injections aren't just about stealing data or something, they can be used to compromise the entire server. There are tools which do this automatically. No, addslashes() is indeed not secure. It's even worse than mysql_real_escape_string(), because it always uses ASCII instead of the actual character encoding of the string. If the encoding of your database connection happens to be incompatible with ASCII, the whole function is useless. In addition to this, the configuration of your development server is obviously broken. It's not normal to remove backslashes from database values. This will break the data when the code runs in a proper PHP environment, because then you'll be removing actual text backslashes. Last but not least, I suspect plenty of cross-site scripting vulnerabilities in your code due to the lack of HTML escaping. This can be used for direct attacks against anybody who visits your website. The code definitely isn't ready yet. The very least you need to do is get the escaping right, both the SQL-escaping and the HTML-escaping. To learn about the new database interfaces, see this tutorial about PDO.

Hi, there's obviously a lot of confusion regarding escaping. Since escaping is also critical for security, you definitely need to understand this before you consider uploading your application. First of all: mysql_real_escape_string() and htmlspecialchars() have absolutely nothing to do with each other and serve two entirely different purposes. The function mysql_real_escape_string() prepares a PHP value in a way that it can be inserted into a MySQL string literal. Let's say you want to insert the following string into the database: The president's daughter Obviously, you can't just take this string and drop it right into a query, because this leads to a syntax error: INSERT INTO whatever (content) VALUES ('The president's daughter') -- this is invalid syntax ; If the PHP value comes from the user, they can even exploit this bug to break out of the string literal and manipulate the query itself (see SQL injection). To prevent this, all special characters like ', " and \ must be escaped by prepending a backslash. This tells MySQL to interpret those characters as literal text rather than MySQL syntax: INSERT INTO whatever (content) VALUES ('The president\'s daughter') -- this is valid syntax; the inner quote is now literal text ; Note that SQL-escaping only works within quoted string literals. If you forget the quotes, you again have a bug which can be used for SQL injection attacks. It's also important to know that manual escaping is extremely error-prone. Programmers have screwed up again and again, and this has lead to a constant stream of security vulnerabilities in web applications. People simply forget the escaping from time to time, or they forget the quotes, or they mess up the character encoding (which can render the function useless). A much better solution is a parameterized statement which separates the data from the actual query. However, this feature is only supported by PDO and MySQLi (I strongly recommend PDO). Whenever you want to insert a PHP value into a query, you must either use a parameterized statement or manually escape the value and wrap it in quotes. Inserting raw values is a bug. You said you're getting literal backslashes in your database when you use mysql_real_escape_string(). This has nothing to do with the function and is caused by some other part of the program or a misconfiguration. If you got some really, really old version with a bad configuration, it could be a problem of “magic quotes”. What does this say:? var_dump(get_magic_quotes_gpc()); The function htmlspecialchars() is an entirely different thing. I guess you should first fix the database issues.