Jacques1

Locking out a user for 48 hours is insane. This allows anybody to lock out your entire userbase simply by repeatedly entering wrong passwords. It's denial-of-service made easy. We've discussed this topic back and forth in the last few weeks, so you should search the forum for it. My personal stance is that log-in limits are complicated, user-hostile and ineffective. Before you do anything, I strongly recommend that you actually think about the problem: What are you trying to achieve? Does a log-in limit really solve your problem? Is there maybe a better solution? So what are you trying to achieve? Why would you want your poor users to wait for 2 frigging days before they can access their account again?

Why does a character like the ellipsis cause trouble? This is not normal. You should rather fix this problem than come up with weird workarounds.

You're in the wrong forum, this is obviously an SQL question. ... ORDER BY good DESC, best_time ASC LIMIT 1

No, it doesn't solve anything. Obviously there's something very, very wrong with your application or server, because this url(...) stuff is actually present in the sessions. It does not come from the browser, because then you wouldn't be able to remove it with PHP. I strongly recommend you figure out how the data got into the sessions. And you need to learn HTML-escaping.

The security of TLS/SSL depends on identities. All the encryption is worthless if the data goes to some man in the middle rather than the target server. In that case, you might as well send them the plaintext right away. TLS/SSL only works if you can rely on the certificate, because that's what binds a public key to a specific identity. In the case of standard certificates, we don't really have a good reason for relying on the information. All we know is that somebody has submitted a signing request and was able to confirm the token from the automated confirmation mail. Was it the site owner? Hopefully. In the case of EV, however, we can be pretty sure that the certificate is indeed the right one, because the CA has actually checked this. So EV does increase the security of the site. It prevents man-in-the-middle attacks. Of course it doesn't help you with SQL injection problems or server misconfigurations, and it doesn't cure AIDS either. But I don't think anybody made that claim. We're talking strictly about network traffic security. Again, I'm not saying that every small company can and should afford EV. But the security benefits are unquestionable. The green bar is indeed a strong security indicator, not just decoration.

What's the whole point of this class? It seems to be a lot of code for very little functionality. If you're looking for database abstraction and convenience, PDO is the way to go. I wonder why people use MySQLi at all.

*lol* Verifying the identity of the site owner is the whole point of a certificate authority, and it's absolutely crucial for the security of TLS/SSL. If an attacker is able to obtain or forge a certificate for your site, they can act as a man-in-the-middle and read the entire traffic between you and your clients. Standard certificates offer little protection against that. The verification procedure is automated and only consists of sending a (plaintext) e-mail with a random token to some admin mailbox. If an attacker has access to that mailbox or is able to intercept the incoming mails, then you're screwed. Extended Validation is very different. The validation is done by actual people who will call you and ask you all kinds of questions to make sure the certificate request is legitimate. EV certificates also don't use insecure algorithms like MD5 (standard certificates did). So, no, EV is not just “a fancy green bar and some random information”. It's how validation should be done. But of course this is very expensive, so you have to ask yourself if you're willing (and able) to pay hundreds and thousands of dollars throughout the lifetime of the site. For the beginning, I recommend you start with something cheap. Note that StartCom (the company behind StartSSL) does charge $24.90 for certificate revocation. A lot of people were suprised when they had to revoke their certificates after the Heartbleed Bug and found out that their “free” certificate suddenly costs a lot more than a standard certificate. So it's not really free.

The \s pattern matches a single whitespace character. This includes the space character, the tabular and the various newline characters. No. As I already said, the meaning of the “.” pattern depends on the regex modifiers. By default, “.” matches any character except a newline. If you want it to match a newline as well, you need the “s” modifier. The “*” is a greedy quantifier: It consumes as many repetitions as possible. On the other hand, “*?” is a non-greedy quantifier, which means it consumes as few repetitions as possible. Using “.” is generally poor practice, especially when combined with a greedy quantifier. What happens is this: The pattern first consumes the entire line or even the entire remaining input (depending on the modifiers). Since there's no input left, the regex parser can't find a match for the next patterns. So it goes one step back and tries again (this is called backtracking). If it still can't find a match, it again goes one step back and tries again. And so on. This trial-and-error procedure is obviously extremely inefficient. In the worst case, the parser has to go all the way back to where it started and then starts over. Not good. When you write regexes, be specific. Tell the parser exactly what you want. If you use vague patterns, then the parser has to guess what you want and will take much longer. I also recommend that you read up the basics of regular expressions. There are tons of online resources and books. Just google for it.

Read the manual, especially the part about the “s” modifier.

No, no, no. There are a lot of misunderstandings on both sides, and you're about to waste a lot of money. First of all, why would you want separate domains for the registration, the log-in form and the log-out function? This makes no sense. Maybe you don't know what a domain actually is. Let's say the full URL is this: https://www.yoursite.com/register.php The domain is “www.yoursite.com”. Your PHP scripts do not belong to the domain, so you can and should serve them all from the same domain. Subdomains are something like “static.yoursite.com”. They're useful in some special cases, but unless you know exactly why you need them, you don't. So a simple certificate for a single domain (which is much, much cheaper) should be sufficient for you. Note that the “www” subdomain is usually included, which means the certificate automatically covers both “yoursite.com” and “www.yoursite.com”. Even if you do in fact need multiple subdomains, there's still no reason for buying an expensive wildcard certificate. There are so-called “multi-domain certificates” which cover a couple of arbitrary domains (not just subdomains as CroNiX said!). Long story short: Do you even need multiple domains, or was this just a misunderstanding?

If you like to make big, exaggerated statements, then don't complain about getting a response. I actually did believe you were having a blackout, because you're usually smarter than that. And indeed your revised opinion sounds a lot more like you. So now it boils down to “too much effort for too few users”? Well, in this specific case (I'm not interested in hypothetical situations), we're talking about one if statement. That should be doable. I have to idea what the reference to HealthCare.gov is supposed to tell us. While I don't have first hand experience, it seems the whole project was a disaster. Is that an argument for their JavaScript policy? Is it the new standard of web programming. I don't think so.

Because a programmer who proudly announces that he punishes users who care about their security and privacy is either drunk or out of his mind. I was hoping for the former. Well, or maybe you simply have no idea why people choose to restrict script execution. So let me try to explain. As much as we like to think of web applications as great pieces of software, they rarely are. Many developers have never heard of basic security features like escaping. And even the ones who do understand the concept still don't always get it right. As if that wasn't bad enough, site owners also love to clutter their pages with questionable tracking snippets, fishy third-party ads and plain nonsense. You don't have to go to “the dirtiest alleyways of the intertubes” to realize this. Just read a few threads on this forum. Or some code on GitHub. Or the security announcements of your favorite framework. Or the CVE. The top vulnerability right next to SQL injections is cross-site scripting. It's the right of every user to protect themselves against this with tools like NoScript. Sure, not everybody exercises this right, because they aren't aware of the problem, or maybe they just don't care. That's OK. But users who do value their security and privacy deserve respect. Does that mean we can never use JavaScript again? Of course not. If it's required for a certain feature, go ahead. Most script blockers allow the user to whitelist specific scripts. But enforcing JavaScript only to punish security-oriented clients and “make their experience miserable” (WTF?) is incredibly ignorant and says a lot about the general attitude towards users.

Are you drunk? I hope so.

Unfortunately, cache invalidation isn't quite that easy. If you permanently refresh the cache, the whole exercise becomes pointless; if you don't refresh it often enough, you risk missing an update. In a non-trivial application, the content may be changed in all kinds of places, which means you'll have a lot of trouble keeping the cache up-to-date. Sometimes there are out-of-order updates (e. g. manual changes in the database). Caches can improve performance, but they can also be a big pain in the ass. So don't do it unless you have to.

“Being online” is a fairly vague term, and there are different definitions and techniques. Sure, you can track the activity of a user, but that's “being active”, not “being online”. If I read a longer text on the screen, I'm not gonna click around, so you'd consider me “offline”, even if I have your site right on front of me. My definition of “being online” looks more like this: there's an active session JavaScript is enabled, and there's at least one browser window/tab pointing to your site; or: JavaScript is not enabled, and the last request was less than n minutes ago This covers both active and passive use, so your users don't have click all the time just to prove that they're still there. To check if there's still an active browser window, you need a heartbeat function which makes an Ajax request every few seconds. If there's a gap in this pattern, it's safe to assume that all windows have been closed. If there's no heartbeat at all, then JavaScript is not enabled.

Before you start optimizing, you need to actually know what to optimize. You have it backwards: You randomly picked a bunch of techniques that you somehow liked, but it's entirely unclear if that's even your problem. Optimization needs to be done systematically: Do you have a performance problem at all? If yes, how big is it? Are we talking about “I'd like to save a few microseconds” or “My clients have already complained”? Are you sure that the problem is caused by your application? Have you ruled out the hardware, the webserver and the network? If it's indeed your application, have you profiled it to find the actual bottleneck? When you know exactly where the problem is, then you can fix it. It's like debugging: When your application crashes, you need to find out the specific problem. You can't just pick a random script and shuffle a bunch of characters.

So what is the error? What does MySQL say? Syntactically, the query is perfectly valid.

@ignace: I do not question your skills and your experience, and I've gone overboard with the previous reply. I'm sorry. However, I do think that simplicity is very important, more important than perfect extensibility. If NotionCommotion actually decides to use APC somewhere in the future, he can simply replace the Configuration class (while keeping the interface). That's only a matter of a few minutes, it won't happen too often, and it makes the code so much easier. Keeping all kinds of different implementations in a factory seems overkill. But like you said, the decision is always up to the OP.

It doesn't matter. Since they're optional, I see no reason for adding them.

Great idea! Since PHP beginners seem to be mostly interested in copy&paste, we might want to focus on easy-to-digest code snippets with very little text. Like a non-evil w3schools.

Buddy, it's actually you who permanently hijacks discussions with his “I'd-rather-be-a-Java-programmer-but-they-only-let-me-do-PHP” overengineering nonsense. When a user just wants to do a simple SQL query, you tell them to set up an ORMAbstractQueryBuilderInterfaceProvider, because SQL is sooo 2000, and they totally need to support MongoDB and CouchDB and Redis and who-knows-what. If they just want a simple configuration for their scripts, you tell them to use an APCFactoryConfigurationObserver, because an INI file just ain't enterprisey enough. We totally need APC. And Elasticsearch. And of course lots of XML. What's the matter? You seem to spend your entire time in that OOP hipster ivory tower, turning even the most simple problem into a pattern massacre with 500 interfaces. Do you know “FizzBuzzEnterpriseEdition”? That's what I'm talking about. Yes, there are tons of fancy design patterns, and I applaud you for knowing all of them. But we're not here to show off our mad OOP skills. We're here to solve real problems in the real world. Just think about it: NotionCommotion currently has a simple INI file, and this is perfectly legitimate. In a couple of years, he might want to replace that with a different format like, say, JSON. That's it. One configuration class, maybe one interface (as I already suggested), and we're done. If you tell him to set up a ConfigurationFactory so that he can have APC and INI and arrays all at the same time, you're entirely missing the point. Don't get me wrong: I admire you for your theoretical knowledge. If I had a question about some design pattern or the latest Java trends, I'd surely ask you. But that's not the topic of this thread. If you want to talk about something else, you should create your own thread.

The colons are perfectly fine, nothing wrong with them.

So? Install mysqldump in your PHP environment and run it from there.

Why are you even trying to write your own implementation of mysqldump?

Use an appropriate library, not this crappy built-in HTTP stuff. PHP supports cURL which is a well known library for HTTP and other protocols. Make parallel HEAD requests (CURLOPT_NOBODY set to true). This way you just ask the webserver for the response code rather than unnecessarily downloading the actual file content. And the requests don't have to wait for each other. Depending on how exactly the counting works, you may also optimize that.