Jacques1

How on earth did you even end up with this weird problem? What's the overall goal you're trying to achieve? The second part sounds like you're webscraping somebody else's site, but then why would you validate the markup? To file a complaint if it's invalid? Or is this your markup? Then why would you choose HTML as your data format? That's a terrible choice compared to pretty much anything else.

Why should it not be possible? WordPress is a normal PHP application. However, this should be done by somebody who knows what he's doing. Poorly managed WordPress sites are a popular target for attackers. There are countless PHP blogs and CMS applications which can be used for blogs. However, you'll have to be a lot more specific if you want any kind of advice.

The file must be locked, otherwise concurrent processes are free to trample over each other, and the file content is nondeterministic. So a proper flat-file database actually requires a lot of code, and then it's still just a lame hack compared to an actual database. Why not use the SQL database on your server as suggested by ginerjm? PostgreSQL even has data types specifically for IP addresses. And if you don't have any SQL database at hand, there's still SQLite. Another problem is the way you fetch the client's IP address: getenv(REMOTE_ADDR) There's no such thing as REMOTE_ADDR. If you fix your error reporting, you'll get a notice about an undefined constant. The only reason why this works at all is because PHP assumes you meant the string "REMOTE_ADDR". Don't rely on that error correction; if you want a string, use a string. Using this environment variable is an odd approach and appearently only works in specific environments. You should use the $_SERVER superglobal. The REMOTE_ADDR will be “wrong” if the client is behind a proxy server. If you want a more reliable result, you need to check other fields as well like $_SERVER['HTTP_X_FORWARDED_FOR']

How about fixing the date in the database instead of messing with code hacks?

Be aware that an UPDATE query will only change the current images. A new photo will be unmarked until you run the query again. If you want to automatically update the flag (like you said in the original post), a quick workaround would be a trigger. But of course none of this is a replacement for an actual developer who knows what he/she is doing and can fix the application itself. To use it in conjuction with LIMIT or to prevent constraint violations caused by an unordered UPDATE. There are several examples in the manual.

That's why I'm asking about the command line. I see no indication for a PHP problem, but this may very well be a network issue (e. g. a firewall which blocks outgoing HTTP requests). Without concrete information, there's nothing I could do from here. Check the firewall settings. Download a file from the command line (however this may work in Windows). When in doubt, use a packet sniffer to anaylze the exact network traffic.

What happens when you use cURL or wget on the command line without PHP involved? Either way, you must have error handling when you call an external library. The fire-and-forget strategy doesn't work (as you can see). Check for errors, log the message, and I'm sure you'll get useful information.

I'm not your bro. The URLs in this forum are probably generated dynamically. As I already said, it's just the ID concatenated with a URL-friendly version of the title: function get_topic_url($topic_id) { $title = get_topic_title($topic_id); return $topic_id.'-'.slugify($title); }

So you're trying to get the ID of the record you're just inserting? That's impossible. MySQL cannot predict the future. What's the whole point of the seourl field, anyway? If it's just the ID and the slugified title, then you can create the URL dynamically. There's no need to physically store it in the database.

It's generally an odd approach to insert the filename before the file is even created. If anything goes wrong, you'll be left with garbage records pointing to files that don't exist. And then there's the total lack of security. You accept arbitrary files and put them straight into your document root. You don't even prevent request forgery, which means the uploaded files could come from absolutely anybody. It almost like improvised FTP. Since you appearently offer quasi-professional services, I strongly recommend you take security more seriously and implement the upload properly. Don't just copy-and-paste the example code from the PHP manual (or wherever you got this from).

One last thing: Password policies exist to make corporate bureaucracy happy and provide a legal cop-out for incompetent superiors. A developer should understand that. The idea that users will make smart decisions if you bombard them with stupid rules and then beat them into submission is just silly. Does any of you function like that? When I encounter one of those security-by-bureaucracy forms, it makes me want to punch the site owners in the face, and I won't do anything but the bare minimum to escape the procedure. In other words, instead of shitty passwords with less than two digits, you now get shitty passwords with at least two digits. Congratulations. If you want actual security, you have to work with the user. Coming up with arbitary rules and telling people that password security is now their problem doesn't work. You need to provide incentives and realistic solutions. No password policy has ever made me choose better passwords. But a single link to KeePass did convince me. It's impossible to cover all absurd rules people come up with. If you use symbols, they aren't permitted. If you don't use symbols, they're required. If you use long passwords, they're too long, If you use short passwords, they're too short. And then of course everybody has their favorite characters and pet theories about password strength. It's just annoying. It's one of those stupid traditions which never seems to die.

So you're here to practice wrong solutions for hypothetical problems so that you can please stupid customers? Good lord. But thanks for reminding me that I have better things to do on a Sunday.

First off: Password rules suck. Unless you're contractually obliged to implement this, just don't. Not only is the security benefit highly questionable; it can be downright counter-productive to enforce a specific pattern, because this leads to problems with purely random passwords (which are in fact the strongest possible choice). For example, I generate and store my passwords with a password manager. If you enforce a certain number of digits, special characters and whatnot, I have to do a lot of extra work and maybe even weaken the password only to make the validator happy. That obviously makes no sense. A far better solution is to provide a password strength estimator and point your users to password managers. Inexperienced users will get positive feedback and may actually learn something, experienced users have a chance to opt out of the procedure. If you absolutely must implement a password policy, do it with code. Sure, we can give you a long, cryptic regex for your rules, but if even you cannot understand it, why on earth would you want it in your code? <?php // Just say no $regex = '/\\d\\D*\\d/'; var_dump(preg_match($regex, 'exam22ple')); var_dump(preg_match($regex, 'exam2pl2e'));

It is bad. First off, “1”, ... “5” aren't even valid identifiers. You can make them work with the backtick hack, but that's just cumbersome, error-prone and confusing, especially when somebody else might have to work with the application. Secondly, storing list elements as individual columns is inefficient in every aspect, it's an administration nightmare, and it forces you to constantly come up with hacks for even the most trivial tasks. For example, how do you count the number of selected items? You can't just use COUNT(*). You either have to manually go through all columns to calculate the sum of the values, or, which is even worse, you have to mess with the MySQL meta tables. And if you do need a new column in the future, you have to rewrite all of that code everywhere in your application. What if there were 100 items? Would you create 100 boolean columns and carry them around for the lifetime of the application? SQL isn't Excel. Your layout may make perfect sense for a spreadsheet, but it makes no sense in a relational database system. In SQL, data is stored as rows. That's really the entire premise. If you need to store list items (regardless of the number), you create a table with one row per item. As a rule of thumb: When you start numbering your columns, there's a design problem.

I hope “columns” actually means rows. If you've added a column for each element of the list, that's just as bad as stuffing comma-separated values into a VARCHAR attribute.

If you add placeholders, yes.

So you want to spend hours on an obscure stored procedure, table locks and who-knows-what so that you can have a cumbersome composite key instead of simple sequential IDs? Sorry, but none of this makes any sense whatsoever. I understand you find those “natural keys” pretty, but that doesn't mean you should suspend all rationality. A bad idea is a bad idea.

I think you're drawing the wrong conclusions. Null byte injections are a fundamental problem for all features implemented in C, which includes the PHP core. Sure, the PHP developers may have fixed some of the most important functions, but the problem may resurface at any time, be it in other core functions or in a PHP extension you're using. It actually has happened again and still happens. If you search the PHP change log for “null byte injection”, you'll find an alarming number of vulnerabilities accross all PHP versions, including the latest ones. So instead of relying on PHP to do the right thing, you should fix the problem and not pass any invalid paths to the lower layers of PHP. You don't need a regex. The ctype_alnum() function checks a string for alphanumeric characters (according to the current locale).

And if field 1 and field 2 are empty but field 3 is filled out? In other words, does it make sense to have, say, a job city but no other information? I expect not, which brings us back to my original interpretation.

You should fix your other problems first. The logic you've described is rather confusing. Are you saying that if the job title is empty, all other fields must be empty as well? Right now, you're forcing the user to always fill out the job title but never fill out any of the other fields.

Why are you splitting the table?

What about backslashes? Or null byte injections? Neither blacklisting nor trying to fix invalid input is a good approach. When you maintain a blacklist, there's a good chance you've missed one of the more obscure cases. And when you change the input, you may create the very vulnerability you're trying to prevent. For example, a seemingly valid mitigation would be to just remove all “/..“ substrings, but then “//....“ will in fact be turned into “/..“. I know that's not your approach, but it demonstrates the underlying problem. You should validate against a whitelist, i. e. reject everything that you haven't explicitly marked as safe. In your case, probably the only valid characters are the alphanumeric ones, the underscore and maybe the hyphen. If the name doesn't match this pattern, there's something wrong, and the script should be aborted. An even safer approach would be to mantain an actual list of possible names, but that may be impractical.

The dependencies which DI is supposed to avoid are hard-coded names of associated classes. This includes the ones you've mentioned, but there's also the Database class which has hard-coded references to constants of some Config class, making it impossible to use any other configuration mechanism. Class constants are particularly nasty, because they cannot be set dynamically at all. I cannot have an external configuration file, I cannot temporarily switch to different settings for unit tests. My only choice is to manually edit the constant values in your class. With DI, you let the caller choose a class; they can even implement their own. You only create an interface to specify the expected methods of the class. In this particular case, however, you can just pass the connection parameters as arguments to the constructor. No need for any classes. Besides that: I understand you currently want to keep your framework as simple as possible, but if you plan to use this for any real website in the future, I strongly recommend you write secure and correct code from the beginning. It's trivial to add features like DI at a later stage (which is why it was my last suggestion), but it's very hard to analyze an entire project for subtle vulnerabilities and try to fix them with ad-hoc solutions. Chances are you'll miss some of them and end up with actual security issues. Whenever you encounter a critical problem like the local file inclusion vulnerability, fix it immediately. It's far more important than optimizing the framework architecture.

You should split the data into atomic values (the first normal form). If there's a street and a landmark, there should be a street attribute and a landmark attribute. Additional data (e. g. the house number) also belong into separate attributes. The reason is simple: Once you've put multiple pieces of data into a single field, it's very difficult or even impossible to extract the individual parts again. The approved_by_..._manager_id fields should be the actual staff member IDs so that you know who recruited the person. If the manager is always the same person or you don't care who he/she is, the approved_by_manager field can be a simple boolean. Whether or not a person is recruited can be derived from the approved_by_... fields and your rules. You can store the result in an extra field if you think that simplifies your application, but it's not necessary for the data itself.

I'm not aware of any complex multi-table insertions required in the above layout. Can you give an example? Most tables cover mutually exclusive cases, so they are by definition not used together. Generally speaking: In a non-trivial application, it's perfectly normal and unavoidable to handle multiple tables. That doesn't mean you need transactions all the time, because not all insertions actually happen simultaneously. If you do need to insert data into multiple tables at the same time, a transaction is the simplest way. All you have to do is start the transaction and then either commit or rollback, depending on whether the action succeeded or not. Why are there two addresses but only one city, state etc.? What exactly is the address? Yes. Whether (pre-approved) applicants and staff members can share the same table depends on the data you want to store. Normally, actual staff members require more information than a person who has merely applied for a job. But that may be different in your case.