requinix

Who wrote the original code?

You're not checking the password at all... Also, 1. Use POST. 2. Hash the password in your JavaScript before sending it in the URL and/or use SSL.

Does it still do that if you use a different browser?

Depends on the server...

You did? I don't see how.

The easiest change would be to use the /e flag. Causes preg_replace() to evaluate the replacement string (after substitutions) as PHP code rather than a literal string.

To be pedantic, you should also addslashes() for JavaScript string issues and htmlentities() for HTML issues. htmlentities(addslashes(urlencode($quizTitle)))

1. Forms always have methods. It is not possible for them to not have one. If you don't specify one then it is GET by default. 2. Make your process.php check that the form('s fields) were submitted using whatever method it wants. For a login form you must use POST - otherwise, with GET, the credentials will show up in the URL and that's Bad. if (empty($_POST["userName"]) || empty($_POST["pass"])) { // form was not submitted properly // do something, like redirect or show a login form with error or whatever } else { // form was submitted properly }

A couple more answers since the question is a bit ambiguous: - if that URL is in a string then use parse_url - the whole query string (without the question mark) is in $_SERVER["QUERY_STRING"]

That's true, but why should any of us go out of our way to do the work for you? We'd love to help you do it, though, if you're willing to put some time into it.

In terms of SQL injection, no there isn't anything you need to do once something in the database. There's still XSS injection to think about though. Verify the data is what you expect it to be before inserting it into the database, and use htmlentities() when echoing it out into your HTML. "Usually" isn't enough.

Like, do it for you? How much are you offering?

Uh huh. Are those three the only possible patterns? Then you don't need regular expressions: just test for the differences between each one. Like components have a hyphen at the 5th position, spares have one at the 3rd position, and clothing is the odd one out. if ($row["Part_No"][4] == "-") { // component } else if ($row["Part_No"][2] == "-") { // spare } else { // clothing }

You get what error?

I don't suppose this thing you're running has a daemon mode, right?

Yes, and for that reason. No. The first reason is that the values might contain quotes that will mess up your SQL queries. You need to protect against that happening, whether it's accidental or not. The second reason is a blanket rule: you cannot trust anything that comes from a browser. Period. If they're an administrator it doesn't matter. If you have JavaScript validation or sanitization it doesn't matter. It's all equally untrustworthy. If I understand you right, only do it the one time. mysql_real_escape_string() give you an altered string that's safe for SQL queries - it doesn't do any hidden magic like mark a variable as special or whatever. If you did it a second time on the new string then you'd be doubly-escaping it. Yeah, that's fine. Vast majority of scripts don't need two database connections open at once so it's rarely a problem.

This topic has been shift+dragged to MySQL Help. http://www.phpfreaks.com/forums/index.php?topic=353982.0

How about this structure? orders order_id | ... ---------+---- 1 | 2 | 3 | products product_id | color | size | ... -----------+-------+--------+---- 1 | blue | small | 2 | blue | medium | 3 | blue | large | 4 | pink | small | 5 | pink | medium | 6 | pink | large | orders_products order_id | product_id | quantity | ... ---------+------------+----------+---- 1 | 1 | 3 | 1 | 3 | 3 | 2 | 2 | 5 | 2 | 5 | 5 | That's a fairly typical setup for this kind of thing.

Now that you're in the Regex forum, take a look at some of the stickies at the top of the thread listing. They should be able answer your questions.

This topic has been... uh... whatsit... moved? to PHP Regex. http://www.phpfreaks.com/forums/index.php?topic=353911.0

Semicolons are used to terminate queries in situations where (a) it's not always clear when one is finished, and (b) when there could be more than one query provided. Neither is true with what you provide to mysql_query(). Whatever the reason, MySQL themselves have said explicitly that you should not include it: http://dev.mysql.com/doc/refman/5.5/en/mysql-query.html

1. You need quotes around the title string. 2. You need to use mysql_real_escape_string on that title first. 3. Don't end your queries with semicolons. This is not the circumstance when they're supposed to be used. "INSERT INTO posts (title) VALUES ('" . mysql_real_escape_string($_POST['title']) . "')"

Two methods. The one I prefer is to use some JOINs SELECT c.content_id, c.content_title, c.content_body, co_p.value AS price, co_w.value AS weight, co_s.value AS sale FROM content c LEFT JOIN content_options co_p ON c.content_id = co_p.content_id AND co_p.option = "price" LEFT JOIN content_options co_w ON c.content_id = co_w.content_id AND co_w.option = "weight" LEFT JOIN content_options co_s ON c.content_id = co_s.content_id AND co_s.option = "sale" (outer joins, just in case the price/weight/sale value is missing) and the other is subqueries SELECT c.content_id, c.content_title, c.content_body, (SELECT value FROM content_options co WHERE co.content_id = c.content_id AND co.option = "price") AS price, (SELECT value FROM content_options co WHERE co.content_id = c.content_id AND co.option = "weight") AS weight, (SELECT value FROM content_options co WHERE co.content_id = c.content_id AND co.option = "sale") AS sale, FROM content c

If you want preg_replace() to treat a string as PHP code to evaluate then you need to use the /e flag in the search expression. Then make the replacement string be the code you want executed. Also, you really shouldn't be HTML encoding anything until it's about to be displayed. However that's the general case: in your situation you should have two separate fields in your database table for the post text. One of them is the original text so you don't have to reverse-engineer it, and the other is the HTML-ready text so you don't have to parse BBCode and such every time you want to display it.

Because they know something we don't: that there are two different lookup results, for whatever reason, and can gather the results from both into one report.