requinix

- Without going through the source code, I believe GD will write the image from scratch, because otherwise it would have to remember all the little bits of fluff it encounters when loading the data - and then write them back, assuming that the fluff is still accurate even after modifying the image. (Saying this because I know specifically of a few things that depend on the image data, thus changing the image data screws them up.) - JPEGs are best for photographs. If people upload a PNG then it's quite possible they're not uploading a photograph (eg, some icon or glyph), in which case you probably want to keep it as a PNG. Then there's GIFs which can be animated. So it'll probably be better to keep whatever format they use. - GD is quick and simple but isn't that great at preserving quality during operations (especially with palette images). If you need to keep quality, try ImageMagick instead.

Look into KML. Much easier.

What it sounds like you're asking, no. The referrer is the only piece of history the browser sends (if it even does) and it's only the previous page (supposedly).

Such as index.php?location=index.php And boom goes the dynamite.

Substituting that whole segment? You can just find the "/ref=" and grab everything else after it - don't need any "numbers, letters, and underscores" logic. #/ref=.*#

Do any of the values have a dollar sign? Like $25.00? Or the generic question: what are the exact values of those two variables?

Which looks like...?

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.