Jacques1

I think there's a lot of confusion about the basics. If the browser supports HTML5 and the user leaves a required field empty, then the form isn't submitted at all. That's the whole point. And if the form isn't submitted, then your PHP script is never executed. The only way to see your custom error messages is to use a browser without HTML5 support (or circumvent the form validation). In that case, the form will be submitted despite the empty fields and trigger your server-side validation.

Of course you do have a point that formal validation alone doesn't really prove anything. So, yes, it might make sense to also check the DNS records. Depends on the problem.

There's a difference between a domain and an HTTP URL. A domain is simply an identifier in the DNS system. It doesn't have anything to do with web pages, response codes or whatever you may have in mind. A domain doesn't even have to map to an IP address. For example, it's perfectly valid to set up a domain exclusively for e-mail addresses. In that case, cURL wouldn't even manage to resolve the domain. But even if the domain happens to point to an IP address (which is not a requirement in any way), that still doesn't mean there's a webserver on it. For example, I have a machine exclusively for VPN. There's no Apache anywhere, any attempt of connecting to port 80 or 443 will fail. Does that mean the domain is invalid? No, it simply means it's not meant for the WWW. But even if there happens to be an IP address with an active webserver, that still doesn't mean you'll get a 200 response code for the specific path “/” (I guess that's what you meant). Maybe the only valid path is “/index.html”. Does that mean there's something wrong with the domain? No. I understand that browsers make us think the entire Internet consists of websites: You type some domain into the address bar, and automatically a website pops up – and if it doesn't, then “the domain is invalid”. This is very wrong. The Internet is much broader than the WWW, and the original poster didn't say anything about checking websites. The question was about domains.

Did you read any of the replies? Repeating the same wrong statements and nonsensical code snippets isn't gonna help us. You need to read the replies, understand them and have a discussion with us. Again: The regex does match your valid examples. It really does. If you get different results, there's something wrong with the way you're testing your code. Try this: <?php $domain = 'mkyong123.com'; if (preg_match ('/^((?!-)[A-Za-z0-9-]{1,63}(?<!-)\\.)+[A-Za-z]{2,6}$/', $domain)) { $mydomain = $domain; echo 'Match'; } else { $mydomain = preg_replace("/^((?!-)[A-Za-z0-9-]{1,63}(?<!-)\\.)+[A-Za-z]{2,6}$/", "", $domain); echo 'No match'; } You see “Match” on the screen, right? That means the regexes matches the domain. And again: The else part is nonsensical. You cannot replace something which isn't there. If you want to set $mydomain to an empty string, you do it like this: $mydomain = ''; OK?

Um, what? We're talking about domains here, not HTTP resources. A domain doesn't send response codes. There could be a webserver on the machine, and that webserver may or may not send certain response codes for certain resources, but that's an entirely different topic.

You let me download any file from your server? Cool, let's start with your passwords. Guys, please think before you write code. We already have enough of Wordpress vulnerabilities, no need for a new one. If you don't know how to write proper code, then don't write any code at all. Use a plugin, hire somebody or whatever.

Don't just copy and paste code you found somewhere on the Internet, especially when you have no idea what it does. Chances are it's garbage, and it may even cause security vulnerabilities. And indeed that class is both garbage and dangerous. It leaves your application wide open to SQL injection attacks should you every forget to validate the array keys before calling the method. Ironically, Drupal had the exact same vulnerability a couple of months ago – maybe they also copied and pasted that code snippet. Either write your own code or use a reputable library. But don't just copy and paste random code.

None of this makes sense. If there's no match for your regex, you try to do a replacement with the exact same regex. What? You already know that the regex doesn't match, so the replacement obviously won't do anything. Maybe what you actually meant is simply $mydomain = ''. Your examples are processed like you want: The first one triggers the if branch, the second one triggers the else branch. I have no idea how you came to the conclusion that both trigger the else branch. That homegrown regex stuff generally doesn't do much. It will happily accept any garbage as long as it contains a bunch of dots (e. g.“i.do.not.exist” is perfectly valid according to you). If you want a more serious check, use the Public Suffix List.

I'm not sure if IP checks are a good idea. They provide very little protection, and the IP must be kept up-to-date for the lifetime of the application. The check may also break entirely if the server architecture changes (e. g. Apache running behind a front end server and receiving the server IP rather than the client IP). If you are and will be in full control of the server, sure, you can use this as additional protection. But otherwise it probably causes more harm than good. Yes. Two separate passwords. If one password gets compromised, then at least the other password is still intact. If you used the same password, then the hash would actually be rather useless, because the plaintext would be sitting right next to it.

Once you've established an HTTPS connection, you can safely use classical password authentication. So you generate a random password on the web server, store its hash on the fax server (plain SHA-256 is enough), and now the web server has to include the password in every request. You do the same thing in the other direction. HTTPS also supports mutual public key authentication: We all know server certificates, but there are also client certificates which can be used to authenticate the client. This is more secure than passwords, but it's a bit more effort to set up if you've never done it before. HTTPS doesn't require any additional HMAC stuff. It automatically protects against eavesdropping, data tampering and even replay attacks (it's not possible to record a valid request and then send the same data again). Personally, I'm a fan of cleanly designed APIs and standardized protocols like JSON-RPC, so the whole approach looks a bit hacky to me. Sure, wget and echo are theoretically enough to make two parties communicate over HTTP(S). But once things get more complex, you may regret that choice and wish for an actual API with proper error handling etc. It really depends on the job. Do you just need a quick hack so that you can move on? Or is this a serious task which is worth some extra effort?

First of all: Inventing your own security protocol makes no sense, even if it only needs to be “fairly secure” (whatever that means). Coming up with your own stuff usually takes more effort than simply setting up a proper HTTPS connection, custom protocols are almost always fundamentally flawed (yours is), and it's not even possible to reliably estimate their strengths and weaknesses. I mean, even if I told you that your approach is “fairly secure” (which I don't), that wouldn't mean anything. Protocols are evaluated by teams of experts, not a bunch of random guys in a PHP forum. Just use HTTPS with self-issued certificates. It's easy to set up, it doesn't cost anything, and it provides solid security. Knowing how to do this is also a very important ability which will probably help you in the future. As to your protocol: The first fundamental issue is that you haven't defined the goal (or at least you haven't told us). What does “fairly secure” mean? Which threats are you trying to protect against, and which threats are you willing to accept? We can't evaluate a protocol if we don't even know what it's supposed to do. Generally speaking, there are several issues (or properties, if you will): The protocol (obviously) provides no confidentiality, so an eavesdropper can read all data going back and forth. An eavesdropper can also record valid requests an replay them. The hash stuff is dubious at best and uses common anti-patterns. While you've been lucky(?) enough to avoid the even worse construction SHA256(key + message), your variation is highly vulnerable to hash collisions. Granted, there are currently no known SHA-2 collisions. But that's still not an excuse for using a broken scheme instead of a standardized construction like HMAC. If you do the hash validation in a naïve way like $provided_hash == $expected_hash, you'll reveal the key through time differences. The whole idea really only makes sense if you assume that passive eavesdropping is no problem at all (is this reasonable?). But then why do you think that active attacks are a problem? Active attacks are generally more difficult than passive attacks, so it's odd to assume that an attacker can do the former but not the latter. Or maybe you just want to authenticate the client so that a random visitor cannot simply download a document? Then you might as well use a plain password. Again, without a concrete definition, the whole exercise is pointless from the beginning.

If you properly selected the specific columns instead of just doing a “SELECT *”, you wouldn't have those problems in the first place. The “*” is very poor style and commonly leads to bugs like this.

The whole point of HTTPS is to make sure that the client actually gets the site they requested (or nothing at all). If anybody could simply trigger a redirect to a different site, then the protocol would be rather useless. Just think about it: “You want https://www.paypal.com? Nah, I'll redirect you to https://paypal.phishing.ru instead”. That obviously wouldn't be acceptable. It doesn't matter how many new domains you have: If a client visits the old domain, you either have to present a valid certificate for that domain, or they'll get a big red warning. I strongly recommend that you learn the basics of HTTPS before you take any further steps. Distributing “https://” URLs to a temporary domain wasn't very smart, because now you need certificates for that old domain for the entire lifetime of the content. All you can do now is either get a free certificate from StartCom each year or wait for the Let's Encrypt campaign which is supposed to provide free certificates through an automated procedure.

I wouldn't read too much into those templates. A lot of Magento people are unhappy with it as well, so it's probably just legacy garbage. They considered moving to Twig, but decided that it was too much effort to rewrite all old templates. Generally speaking, this template style mostly boils down to igorance and stupidity. There are lots of excellent template engines (like Twig) which offer readable syntax, high performance and increased security all at the same time. Yet still many programmers refuse to use them and stick to plain PHP. Well, OK, there's an alternative PHP syntax specifcally for templates. But again a lot of PHP programmers just don't use it and instead clutter their code with loose braces all over the place. Why? Because they've always done it like that. I've discussed this topic many, many times, but you just hit a wall. I think we'll have to live with the fact that many PHP people want awful code. They produce the legacy shit today that we have to fix tomorrow. <?php echo 'T' ?> <?php echo 'h' ?> <?php echo 'a' ?> <?php echo 'n' ?> <?php echo 'k' ?> <?php echo ' ' ?> <?php echo 'y' ?> <?php echo 'o' ?> <?php echo 'u' ?> <?php echo ',' ?> <?php echo ' ' ?> <?php echo 'P' ?> <?php echo 'H' ?> <?php echo 'P' ?>

Nobody said that you should take warnings less seriously than exceptions – at least I didn't. In fact, a professional developer should take warnings as seriously as any other error. While it's true that they sometimes just indicate poor coding style (which is bad enough), they may very well point to a serious bug. So a zero-tolerance approach towards errors is actually a good idea, because it reduces bugs and enforces basic quality. A lot of languages already work like this. For example, if you try to access a nonexistent index in Java, the application will throw an exception, and there's no such thing as turning off error reporting. What you have to consider, though, is that PHP was designed as a toy language for non-programmers who just wanted to get their homepage up and running and didn't care about the underlying code. That's how it is. So if you reject this approach altogether (which is understandable), it probably makes more sense to choose a different language than to try and turn PHP into something else.

Exceptions are not meant to make programming more convenient for you or save you from writing down isset() checks. This is abuse. The purpose of exceptions is to handle errors. You throw them when a (serious) problem occurs. If you're using them for anything else, then you're generally doing it wrong. So, no, this is not a valid approach. And yes, it has huge negative effects, because now all notices, warnings etc. trigger an exception. In the worst case, you'll even catch an entirely unrelated error and assume that it's just a missing index again. That's not good. On top of this, the whole construct is incredibly confusing. I mean, just imagine yourself trying to explain it to a fellow programmer: “Look, I actually just want to do an isset() check. But since I couldn't do it, I've created a global error handler which turns all notices into exceptions. So this piece of code (as well as all other code) will now throw an exception if there's a missing index, and you have to catch that exception and put the logic into the catch block.” WTF? What's the problem with isset(), anyway? Shouldn't we talk about that rather than come up with weird hacks?

While you're working on your script, it's also time to take password security more seriously. Algorithms like MD5 or SHA-512 are not acceptable. Stock PCs can easily calculate hundreds of millions of SHA-512 hashes per second, so even strong passwords can be found with a brute-force-attack. And since the same input always leads to the same hash, a lot of weak passwords have already been hashed and can be looked up on Google. The only solution is a specialized password hashing algorithm. A common choice today is “bcrypt”, and you'll be happy to hear that it's fully supported by PHP. Use it.

Before you make a big mistake, please also read my comments in #20. Cookies are not a replacement for sessions and will never be, because they can be modified by the client. This remember-me stuff is also very problematic and difficult to implement correctly. I'd say that 99% of the example code you find online is plain wrong and will blow up your entire user authentication. So, please, don't just start implementing some idea that sounds good. If you go beyond standard sessions, make sure you know exactly what you're doing.

What cookie? The PHP session cookie is generated automatically and is needed to carry the session ID.

I'm not talking about usernames, I'm talking about messages. Substrings like “dick” or “ass” or whatever can occur in all kinds of legitimate texts which have absolutely nothing to do with profanity. So you need this to make your hoster happy? Then I suggest you get a proper hoster which doesn't have such stupid rules. You want this chat to be a success, right? Then you can't just ban innocent users who haven't done anything. Nobody will accept this, especially when there are tons of other chats to choose from. If, for some strange reason, you're stuck with your current hoster, then do the bare minimum to formally comply to the rules. Ask them what exactly they expect from you. This certainly does not involve banning users or preventing chats about Charles Dickens.

A ban? You mean a kid who likes Charles Dickens would be thrown out of your chat? C'mon, you can't be serious. Even the best filter has false positives, meaning a legitimate user making legitimate statements will be erroneously flagged. If you automatically ban them, sorry, then your application sucks.

PCRE regexes need delimiters. Like so: '/.../' (note the slashes). Besides that, the whole approach looks rather problematic. If you do a substring search, what happens with “Charles Dickens”? Is this name politically incorrect and will be censored? Of course censorship itself is crap, but that's a different discussion ...

A few comments for clarification: You must not store the user ID or username in a cookie in order to identify the user. Cookies are managed by the client, so they can easily be modified. Nothing prevents a malicious user from changing the name to “admin”, and if your application now thinks the user is an admin, you obviously have a problem. This is why sessions take a different approach: PHP generates a long random session identifier pointing to a session file on the server. The actual session content is kept in that file and cannot be directly modified by the user. The user only gets a cookie with the session identifier. Sure, they could modify their session identifier, but this won't get them anywhere. The chance of finding a valid ID from another user is effectively zero (assuming a proper PHP configuration). So data which isn't supposed to be modified directly may only be stored in the session, not in a plain cookie. It's also not true that sessions are terminated when the user closes the browser. This is just the default behaviour of the session cookies (not the sessions itselves), so both you and your users are free to change this: You may modify the session.cookie-lifetime setting in your php.ini so that the cookies are not destroyed on browser exit. And even if you don't do that, the user may override the cookie lifetime locally or simply restore the cookie when it gets deleted. The session itself is still perfectly valid.

Please don't just write down random code. This ini_set('session.gc_probability', 1) you keep carrying around makes absolutely no sense whatsoever. First of all, why would you want to change the probability of the session garbage collector at runtime? What are you trying to achieve? Secondly, the probability is defined with two numbers, the numerator and the divisor. You can have a probability of, for example, “1 in 1000”, but “1 in undefined” is obviously nonsense. Random code only causes bugs, and additional bugs are pretty much the last thing we want right now. Do this systematically. What were your results with the example code I posted? If you clear all your cookies, visit the first script and then visit the second script, what's the output?

You should not use the example code. It demonstrates the basic features, but it's not appropriate in a production environment with real data and real threats. For example, the script lets anybody place malicious PHP scripts on the server. That's obviously not acceptable. So once you understand the basics of file uploads, you need to deal with security. Check out this article about typical vulnerabilities and how to fix them.