Jacques1

Are you sure that your ezTable() method can handle nested arrays?

nginx has the include directive which does exactly what the name says. I'm surprised you couldn't find it, Darghon. Many settings can also be declared at the top level rather than per server block. This makes life even easier, because the values are automatically inherited but can still be overriden whenever needed. What are those global settings, anyway?

Editors also have this cool new feature called search-and-replace. If yours doesn't, get a proper editor like Notepad++ or an IDE like Netbeans or Eclipse.

“Reserving” the username while the field is being filled out is indeed a bad idea. If you want live validation of the username field, do it in two steps: Pre-check the current input with a simple SELECT. This isn't perfectly reliable (somebody else may still take the name), but it lets the user avoid names that are already registered at that point. When the user submits the form, try to insert the data and catch violations of the UNIQUE constraint imposed on the username field. If such a violation occurs, somebody else has grabbed the name, and the current user needs to start over. A more relevant race condition in your calendar application would be multiple users editing the same entry at the same time. Only the last update will take effect while all others get lost. A common solution to this problem is optimistic locking: You keep a version number for every entry. When the user starts editing, you load the current entry as well as the version number. When the user tries to update the data, you simultaneously check if the version numer is still the same. Only then do you change the data and increment the version number. Otherwise you reject the changes and ask the user to check the new data and try again.

What exactly do you not understand? You need to fix the opening tag in your template.php, and you need to add PHP tags to your functions.php. If you do that, the problem will go away. If you don't, it will persist. Pretty simple. Besides that, you might want to rethink your way of developing. Grab a proper IDE which highlights your code and points out “stupid mistakes” like broken PHP tags. Also install a local webserver instead of testing your stuff on the Internet. If your public website displays a bunch of PHP errors and lets anybody browse through unfinished customer projects, that's not exactly professional. Test code also tends to have a lot of bugs, which can become a serious threat for your production server.

I think you misunderstand gizmola's post (as well as the previous explanations). Nothing gets lost. If 10 people submit the form at the same time, you get 10 new records (I'm excluding errors, bugs and server crashes here). There is no problem. The requests will not overwrite each other or anything like that. The only effect of concurrent submissions is that a user might see both his own entries and the new entries of other users. But that's the whole point of a shared calendar, isn't it? If you don't want this, don't use a shared calendar. Or lock it while it's being edited by one user (probably a bad idea). Again, there is no problem. Concurrency can become an issue if multiple persons edit the same resource (e. g. change the text of an entry), but that's not the case here.

Your functions.php also lacks PHP tags, so the file is treated as HTML. See here: http://www.mediaservicesunlimited.com/bixler/functions.php

You like being the drama queen, do you? ginerjm has provided you with a lot of valuable information beyond your little problem. If you dismiss that just because you think you've detected sarcasm, I'm afraid you're in the wrong forum. We're here to talk about PHP, and your primary concern should be to get accurate information. If you're more interested in meta discussions about the evils of sarcasm, you should probably do that somewhere else.

It means that your webserver accepts any Host header, regardless of whether there's actually a virtual host with that name. This is a matter of configuration. You can either reject all invalid hostnames, or you can map them to a default host. Both is valid and common. If you go with a default host, you'll have to live with the fact that your log contains nonsensical hostnames. I mean automated scanners looking for vulnerabilities. Legitimate crawlers hardly request nonsense hosts.

Nobody above the age of 12 will manually resubmit a form in the hope of overloading your server. This just doesn't work. DoS attacks are automated and can be as simple as a flood of GET requests. There's not much you can do about that except hiring a company to overpower the attacker (which costs money). Also, one IP address does not equal one person! Attackers typically have large pools of IP addresses (think of botnets), legitimate users may share their IP address with thousands of other people. So if a single big proxy server or VPN ends up on your blacklist, you've pretty much DoS'ed yourself. If you want to protect your form against spam, use a CAPTCHA like everybody else. Besides that, you should relax and try to approach this more rationally. Don't jump to countermeasures when you don't even know what you're trying to prevent.

I'm not really sure what you're asking, and you seem to switch between many different topics (server load, race conditions, spam?, attacks?, ...) Yes, a user can submit a form over and over again. So? Why exactly does that worry you?

If you have a default host pointing to your application, then clients can come up with arbitrary hostnames. The Baidu stuff looks like probes, which is generally just background noise on the Internet.

Whoa. You're afraid of 10 requests? Aren't you aware that LAMP powers huge applications with thousands of concurrent requests? That's what a webserver is for! If this is your very first (personal?) website, you should actually be more worried about having too few users.

@joesoaper: So you want us to be particularly nice to you, and at the same time you're free to insult other members? It doesn't work like this. ginerjm's post is probably the most friendly RTFM you'll ever get. If that's already too much for you, you'll have a hard time getting anywhere in IT. Once you start working with other people – be it professionally or in a hobby project –, your code will be criticized. That's simply how programming works: You write code, and then other programmers review it. Maybe you should just relax and assume that people are here to help you, not attack you.

If you insist on using UUID() despite its major weaknesses, just store the plain UUID string. That's really the whole point of the function. If you want a binary ID, generate it with PHP. Some database systems also have a built-in CSPRNG (MySQL isn't one of them). If you don't like passing binary strings around, encode the result with hex, Base64 or whatever you find appropriate.

MySQL uses a weak, obsolete UUID implementation which is based on the timestamp and the MAC address. While this may still be “good enough” for your purpose, a CSPRNG will provide actual randomness with no extra work. Yes, the ID attribute should be unique. I wouldn't maintain an extra column for auto-incremented IDs unless you've actually verified that it's more efficient.

I would actually use www.yoursite.com as the canonical domain for your website, because that's exactly what the subdomain is for: the WWW. In other words, redirect all HTTP(S) requests to www.yoursite.com. The main domain is more like a namespace for different services (e. g. your main site, a forum, a chat, ...).

Note that UUIDs aren't supposed to be unpredictable and may still leak information about your system. If you want to be sure that the generated IDs are in fact sufficiently random, you have to look at the exact implementation or use your own generator.

By far the easiest solution is to get rid of the sequental IDs altogether and use random IDs instead (not as an additional attribute but as the primary key). This is actually very common. You can store a raw 128-bit ID in a BINARY(16) field, or you can hex-encode the random ID and store it in a CHAR(32) field. Also, since you appearently do have a user registration system, why don't you simply use an ACL to prevent users from accessing pages they're not supposed to see?

I'm not sure what you're asking. Do you have numeric IDs, and you want to prevent the client from changing, say, id=3 to id=4? And is there no user authentication? That is, you don't know who the client is?

htmlentities() escapes all characters for which there's a named entity, including characters that don't have any special meaning (like umlauts). I've never needed this and cannot think of any scenario where it might be useful. If you want to prevent attacks and accidental syntax clashes, use htmlspecialchars(). If you want to use HTML entities for other reasons (e. g. to support ASCII-only legacy applications), use mb_encode_numericentity(). ENT_QUOTES is critical for security, because ENT_COMPAT leaves single quotes unescaped and doesn't work for single-quoted HTML attributes. I have no idea why ENT_COMPAT is the default. Since the character encoding is essential for escaping, I'd always set it explicitly and never rely on any defaults (particularly because those defaults have changed). I also use the encoding parameter as a placeholder so that people can insert their actual encoding. Not everybody uses UTF-8.

The ENT_QUOTES flag is crucial for security. If you leave it out, only double quotes are escaped, so single-quoted attributes aren't safe at all. ENT_SUBSTITUTE isn't security-related, but it's still important for Unicode encodings (like UTF-. By default, htmlspecialchars() returns an empty string if the input contains a invalid byte sequence. That's usually not what you want. A more reasonable approach is to substitute the invalid bytes with the Unicode replacement character while leaving the rest of the input intact. And that's what ENT_SUBSTITUTE does.

XSS has nothing to do with databases or input validation. It's an output problem caused by programmers who naïvely insert data (from any source) into HTML contexts. This cannot be solved with validation, because formal validity doesn't mean that the data is safe in every possible context. For example, I could give you a perfectly valid e-mail address which is an XSS vector at the same time. Why? Because the format of e-mail addresses was never meant to protect web applications from XSS attacks. Why should it? it's impossible to predict the context in which the data will be used. There's not just HTML. There are thousands of different languages and data formats with distinct syntax rules, and the data may be a threat to every single one of them. a lot of data cannot be validated at all. For example, how would you “validate” the posts on this forum? We obviously have to write down HTML markup and JavaScript code all the time. That's the whole point of this site. XSS must be prevented during the HTML rendering process. The best solution is to use a proper template engine like Twig which automatically applies HTML-escaping to all outbound data. The second-best solution is to write a wrapper for the htmlspecialchars() function. Using htmlspecialchars() directly is not recommended, because it's extremely error-prone. In my experience, almost nobody understands how to use it correctly. In addition to HTML-escaping, you should use Content Security Policy. This allows you to define strict rules for JavaScript execution and block many attacks.

For simple formatting, there are date() and strftime(), both of which accept a Unix timestamp as a second argument. For more complex operations, there's the DateTime class which can be constructed from a Unix timestamp.

The whole approach sounds rather weird. You've implemented a timer with pure PHP? How does that work? Timers are classical client-side features, i. e. a task for JavaScript. Of course you can and should also store the time on the server to prevent cheating, but all the visuals should be done entirely with JavaScript. Since you're storing the time in the session, what happens when the session is destroyed before the building is finished? Does it simply disappear? You'll probably want to use the database instead. And why exactly do you have to use this weird date("his") stuff instead of a proper timestamp? Do use time()!