Jacques1

Not sure what you mean. You use the loop instead of fetchAll(). Are you still trying to replace the values?

Check your syntax. You've added a closing parenthesis instead of moving the misplaced one. ' WHERE idnumber IN (' . implode(',', array_fill(0, count($_POST['IDnumber']), '?')) . ') ';

Well, like I said, I wouldn't replace the values in the first place. How the data is displayed is a matter of presentation, so it should be done in the HTML part (or whatever the data is used for).

I don't always test my code, so C&P isn't really a good idea. The closing parenthesis for the count() must be right after the $_POST['IDnumber'].

Hi, I doesn't make sense to hard-code a “YES” or “NO” into your array, because like you said, this is only for displaying. Leave the array as it is and do the “YES/NO” thing when you actually display the content. By the way, you neither need fetchAll() nor the old while (... fetch()) pattern. You can use a PDOStatement directly in a foreach loop: <?php $rma_details_stmt = $database->query(' ... '); foreach ($rma_details_stmt as $rma_details) { // ... } You may have to adjust the fetch mode. This can be done per statement or globally for the whole database connection.

What I personally don't like about type casting with intval() or similar functions is that it mangles the user input and turns it into something they didn't ask for. It can also lead to value truncation. For example, if the user (accidentally) enters an invalid value like "abc", you silently turn that into the number 0 and return all items with that ID (if there are any). Why 0? The user didn't ask for 0, they entered an invalid value and should be getting an empty list and/or an error message. Type casting will also lead to problems with big numbers, because PHP integers are limited to a certain platform-dependent range. For example, a 32 bit system can neither hold an INT UNSIGNED nor a BIGINT. If the input is too big, it will be silently truncated. Things like this can cause weird behavior and hard-to-find bugs for both your users and you, so it's probably best to avoid them altogether. I don't think saving one line of code is worth the trouble.

I think you confuse function definitions and function calls. The parameters of a function definition have nothing to do with outside variables. They are generic placeholders which get concrete values when you call the function: <?php /* * This is a function definition; the parameter $name is a placeholder of the function. * It does not refer to any outside variable, even if there happens to be a variable * called $name as well. */ function hello($name) { echo 'Hello, ' . $name . '.'; } /* * This is a function call. This is when you pass concrete values to the parameters * and execute the function body. */ $you = 'floridaflatlander'; hello($you);

Please use code tags (the “< >” in the toolbar above the textarea). What is the $id = $this->db->lastInsertId(); line doing in the middle of the array expression? Is this actually how your code looks like?

Help you with what? What's your question? Or did you expect us to write you a personal PDO tutorial? I don't think that's how this forum works. If you have a concrete question, just ask. But you won't get private PHP lessons for free or something.

You have a database user called “asdasd” with the password “nasdas”?

Personally, I'm not a fan of this type casting approach, because it mangles the user input. Invalid input is invalid input, not “Let's assume you meant the number {some guess}”. And of course this only works with numbers. Generate a list of parameters and then pass your values as usual: $update_stmt = $database->prepare(' UPDATE ... WHERE idnumber IN (' . $implode(',', array_fill(0, count($_POST['IDnumber'], '?'))) . ') '); $update_stmt->execute($_POST['IDnumber']);

I think $data[0] etc. should actually be $value[0] etc. $data is your entire array of rows, $value is the current row.

Hi, the parameters are only for values, not identifiers. Simply set the column name in the query: $search_query = ' ... WHERE ' . ($searchtype == 'store_name' ? $searchtype : 'item_description') . ' LIKE ... '; The ternary operator is just to make sure that $searchtype will never lead to an injection. If you trust your previous validations, you might insert the variable directly.

Cool. By the way, you can leave out the session_write_close(). PHP automatically commits the session at the end of the script.

Well, saying that you couldn't implement this is rather vague. What exactly is the problem? Using DateTime to convert the format is a good solution and works perfectly fine. If you're not getting the expected result, you've made a mistake. But of course we can't help you with that unless you post your code and describe the specific problem.

You really need to get familiar with the manual. The first parameter lists all data types of the bound values. “s” stands for “string”, “i” is for “integer”. If you don't wanna fumble with low-level stuff like this, consider using PDO instead of MySQLi. It's much more convenient. Yes, the higher the cost factor, the harder it is for an attacker to do a brute-force attack against the hashes. But of course a high cost factor will also slow down your own password-related procedures (registration, log-in and password reset). A common recommendation is that you choose a duration you think your users find acceptable, let's say one second. Then you increase the cost factor until you reach that duration on your current hardware. This is the cost factor you use. You can also have different cost factors for different user groups. For example, an administrator should have a higher cost factor than a standard user.

Please read the manual. Or just use common sense: You verify a password against a given hash, so it's only natural that there are two parameters. The first parameter is for the password, the second is for the hash. If the password matches the hash, the function returns true, otherwise it returns false.

The hash part is fine, but the dynamic query should be replaced with a proper parameterized statement: $insert_user_stmt = $database->prepare(' INSERT INTO users (name, email, number, password) VALUES(?, ?, ?, ?) '); $insert_user_stmt->bind_param('ssis', $name, $email, $number, $hash); $insert_user_stmt->execute();

If the child class itself is not abstract, it must implement all abstract methods and may overwrite any of the other methods.

Hi, this is absolutely unnecessary. The session already tells you whether the user is logged in and who she is. So all you need to do is check the session. Speaking of security: The SHA-2 algorithm is not suitable for password hashing at all. A stock PC can calculate billions of SHA-2 per second and find out almost any password simply by trying out different combinations. You need an actual password hashing algorithm like bcrypt. If you have PHP 5.5, use the new hashing API. If you don't have PHP 5.5 but at least 5.3.7, use the password_compat library. Inserting $_SERVER['PHP_SELF'] directly into the HTML document makes the page vulnerable to cross-site scripting attacks. Always escape data with htmlspecialchars() before you insert it into an HTML context. Never trust the user input. While you do escape the SQL input, a much more secure solution would be to use a parameterized statement and separate the data from the query itself.

Hi, and what exactly prevents you from using the WHERE clause or doing a join? Unless your rules are so complex that they exceed the capabilities of MySQL, this is simply a matter of writing one query: SELECT -- something useful, not just "*" FROM products JOIN users ON products.gender = users.gender AND ... WHERE users.id = 1 ;

Hi, messing with the code or validating it in an attempt to make it “secure” (whatever that means) is nonsensical. Content iself is not “dangerous”. This is a common misconception. If an application is vulnerable to, say, SQL injections, that's not a problem of people writing down SQL queries. The problem is that the server misinterprets data as executable code. That's what needs to be fixed. So your job is to make sure that the PHP code is always treated as text and never executed. Storing it in the database is fine, putting it into a file not so much. Running it through the PHP interpreter as suggested by requinix is also something I definitely wouldn't do. And of course you must keep away the code from any evaluation function like eval(), create_function(), preg_replace() with the “e” modifier etc. What do you mean by “verifying that it's a PHP file”? Technically speaking, any content can be considered a PHP script, because there's no rule saying that there must actually be a PHP section. For example, the whole script may consist of plain HTML. In your case, it probably makes sense to treat the entire content as one big PHP section, optionally delimited by explicit PHP tags. So the content either starts with a “<?php” or “<?” tag, or there must be no starting tag at all (in which case the entire content is regarded as PHP code). Then you run the code through an external(!) PHP parser to make sure it's syntactically valid. Note that this has nothing to do with security. It simply prevents users from accidentally uploading garbage data.

Injecting PHP strings into script elements is very risky, error-prone and messy and should be avoided at all cost. Whether or not this works at all depends on several different factors like the inner workings of json_encode() and the flavor of (X)HTML you're using. For example, plain HTML treats the content of script as CDATA, which means any occurence of the term “</script>” immediately closes the element, even if it's inside a JSON string. The only way to get around this is by escaping all forward slashes. The current implement of json_encode() happens to do this by default, but nothing tells us this will always be the case. On the other hand, XHTML treats script as a normal element, which means forward slashes are irrelevant, but you do have to escape the usual HTML characters. And of course inline scripts are just messy and prevent the use of powerful protection mechanisms like Content Security Policy. So why do it? Only to save a single request? I don't think that's worth the trouble.

Hi, the whole approach doesn't make a lot of sense to me, and repeating everything in a new thread doesn't help. First of all, why do you want to keep all queries out of the Team class? Is there a specific reason for this? After all, this is a database-related class, and no abstraction will change that. Unless you plan to give up SQL at some point and move to an entirely different database concept, hiding the SQL queries simply isn't necessary. If you absolutely must do this, then we're back at ORMs. As the others have already said, trying to implement this on your own is nonsensical. Learning an ORM does require some time, so don't complain that this is all too complicated.

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.