PFMaBiSmAd

That's kind of funny. What purpose would limiting failed login attempts be used for?

Using session variables to do this is not secure because all you need to do to get another chance at entering data is to drop the session id and get a new session and the bad attempt count will start at zero. You need to store the count using a method that the visitor cannot reset, such as in a database table.

Only about 5% of the sites I log into have any sort of public member list that would provide username information and on those sites the harm of someone breaking into an account would not be monetary or provide access to personal information. I'm pretty sure on all the rest of the sites it log into, my banking, investment, shopping, travel, API, ... username information is not (intentionally) published on or by the sites I use.

If you don't have "bad login attempt counting/login lockout" logic in your login code (i.e. you allow unlimited attempts), then yes, telling a bot script/hacker specifically first if the username doesn't exist, then if the password was wrong is a security problem.

Edit: Basically says the same as what DavidM posted above ^^^ The problem(s) with the code has nothing directly to do with php4 vs php5. It is old out of date code that would not work under the last recommend php4 configuration either. The code is dependent on register_globals (turned off by default in php4.2 in the year 2002.) It is also using short open tags <? which may or may not be enabled and should simply never be used. Make the following changes - 1) Use <?php for the opening php tag. 2) Change $REMOTE_ADDR to $_SERVER['REMOTE_ADDR']. The one that is inside the message body string will need to be enclosed in {}, i.e. {$_SERVER['REMOTE_ADDR']} 3) Change $HTTP_USER_AGENT to $_SERVER['HTTP_USER_AGENT'] and since it is inside the message body string it needs to be enclosed in {} as well. 4) Change all the external POST variables from just $variable_name to $_POST['variable_name']. For example, $action becomes $_POST['action'] Edit2: Since they are inside the message body string, they will each need to be enclosed in {}

mysqli_error requires the database connection link as a parameter. Again, if you had error_reporting/display_errors set as suggested, you would have been getting php errors that would have alerted you to the problem with the mysqli_error statement. Without the connection link as a parameter to the mysqli_error statement, it does not return the reason why the query failed.

You are mixing mysql and mysqli functions on one connection. That does not work. You must stick to all mysql or all mysqli functions. If you had error_reporting set to E_ALL and display_errors set to ON, you would be getting php errors that would have helped you find problems with mixing the two different type of database functions.

Your logout page is at a different path than your login code and you are not setting the cookie with a '/' as the 4th parameter, so 1) The cookie only matches the path where it was set and 2) the path where you are trying to delete the cookie is not the same as where it was set. Use the '/' as the 4th parameter in all your setcookie() statements so that the cookie will match all paths under your domain - setcookie('User_Id', $row['user_id'],time() +(60 * 60 * 1), '/'); setcookie('User_Id', "" ,time()-3600, '/'); And as already stated, setting simple user id and username values in cookies is easy for anyone to guess and find values that work, such as your user id and your user name.

What is the code that is setting the cookies? The code that is 'deleting' the cookie must use the same parameters as when the cookie was set? What is the code that is testing for the cookie and displaying the - 'welcome "username" ' message? It might have a logic error in it. Also, it is not safe to set cookies with 'simple' and easy to guess values, because anyone can change the value in a cookie and could impersonate any of your site members.

Your code would end up looking like - <?php //^^ SET ARRAYS ^^ $result = mysql_query("SELECT * FROM stock WHERE stock > 0 ORDER BY category,name"); $last_cat = null; // remember the last category while ($row = mysql_fetch_array($result)){ $id = $row['id']; $cat = $row['category']; $name = $row['name']; $price = $row['price']; $new = $row['new']; $stock = $row['stock']; $desc = $row['description']; $new = ($new==1) ? 'NEW' : ' '; if($last_cat != $cat){ // a new or the first category was found if($last_cat != null){ // not the first category, close out the previous section echo "</table>\n"; } $last_cat = $cat; // save the new category // output the heading/start a new section echo "<h3>$cat</h3><table width='800' border='1' cellspacing='0' cellpadding='4'>\n"; } // output the data if($desc==''){ echo "<tr><td width='80%'>$name</td><td width='8%'>$new</td><td width='12%'>£$price</td></tr>\n"; } else { echo "<tr><td width='80%'><a href='viewitem.php?product=$id'>$name</a></td><td width='8%'>$new</td><td width='12%'>£$price</td></tr>\n"; } } // close out the last section echo '</table>'; ?>

Additional to the above, your query would also only return rows that have stock > 0 (there's no point in retrieving data from a database unless you are going to use that data.) Unless, you want to specifically display an item, but indicate it is out of stock (which your code is not currently doing.)

In general, your query should retrieve the rows you want in the order that you want them. You would then simply iterate over the rows once and output the data the way you want it. If you want the categories in the order you have implied (non-alphabetical), you would either need an 'order' column in your table to hold numerical values that define the order the categories should be displayed as or have a category id (rather than the category title spelled out in every piece of data), which you can specifically list in an ORDER BY term to give the desired final order. You could then use an ORDER BY term in your query to get the categories in the order that you want them and all the rows for each category under each category. If you actually want the categories alphabetically sorted, you would just use ORDER BY category in the query. I'm also going to guess that you want the produce names sorted alphabetically under each category? To detect and output the category heading as you are iterating over the rows, see this recent post - http://www.phpfreaks.com/forums/index.php?topic=342450.msg1615618#msg1615618

You have a space in the value after the 'd' and before the single-quote in 'checked '". Use either - checked="checked" or checked='checked'

Classes and functions have their own local variable scope and should not directly be affected by register_globals. It's also possible that you are using such an old version of the phpmailer class (your's is from the year 2003) that it could be importing main program variables into its local variable scope. It's more likely that your code has same name cookies/variables/session variables and register_globals is overwriting your data. Why do you even have register_globals ON? What happens when you turn them off?

^^^ $proof in the above is the result from a strpos statement and will never be exactly a true value and that conditional test will always fail. You would need to use !== false

The way to output a new heading/category/section once, each time it changes, is to remember the last value (initialized to a value that will never exist in the data), detect when it changes and start a new heading/category/section, and remember the new value. The basic logic using the $cat variable that Muddy_Funster posted is the correct method of doing this.

Is the data the same on the two different servers? I suspect that you have a character in a value that is breaking the HTML. You should use htmlentities with the second parameter set to ENT_QUOTES on all data values that you output into a form. What exactly is the 'view source' starting from row 122 to the end of the form. Another possibility is you have the Suhosin hardened php patch installed and it is limiting the total number of form fields. If you exceed the post_max_size, the $_POST array will be empty, not cut off.

To get a specific row out of each group of data, see this link - http://dev.mysql.com/doc/refman/5.1/en/example-maximum-column-group-row.html

So that your code would tell you which field(s) are failing, as that would point to where to look to find the cause of the problem. Right now, you don't even know if it is just one field or all of the fields that are not working.

@dominic600, you replied in the Wrong thread.

This is the classic CRUD (Create, Read, Update, Delete) assignment that is given to programming students to see if THEY can research and figure out how to define and write the code to perform each of those steps. The OP has some code to Read the data and display it in a form (which is incomplete and won't submit any data, let alone sets of data that are related back to the correct id/type of each row in the database table.) I recommend that you get the form working correctly before you attempt to try to process the data it submits. Your form input fields are missing name="..." attributes (no data will be submitted to your .php script without them), you will need to use arrays for those names so that you can have multiple/separate sets of data in the form (see this link - http://us.php.net/manual/en/faq.html.php#faq.html.arrays ), and you need to specifically set the array indexes (instead of using empty [], use ['some_identifying_value']) to identify and associate each row of data in the form back to the id/type it is in the database table. Based on the information in your existing code, you could use form field names like - name="slice['.$row['type'].']" name="small['.$row['type'].']" name="large['.$row['type'].']" name="sheet['.$row['type'].']" To see what data your form is submitting, add the following line of code - echo '<pre>',print_r($_POST,true),'</pre>'; Once you get the form to submit the expected data, you can move onto the next step of processing it.

Yes, you design your log in system so that you simply include it into any page that needs it. If the visitor is not logged in, the log in form is produced and you output it where you want it to be on the page. If the form is submitted, it submits to the current page and the log in form processing code is executed to authenticate the username/password and log the person in. If the current visitor is logged in, you produce a welcome message/log out link and output it where you want it to be on the page.

The recommend way of validating all the form fields individually is to use an array to hold the error message(s). You run all the possible validation tests and then at the end you simply test if there were any errors or not. See the following post for some example code - http://www.phpfreaks.com/forums/index.php?topic=340943.msg1607829#msg1607829

When validating user supplied information, you should supply as much information as possible as to why the information did not validate. You should individually test each value and output a specific message for each validation problem found.

Lines 3-8 of header.php are a bunch of characters that are being sent to the browser. Any characters that you send to the browser before a header() statement will prevent the header() from working. I recommend that you re-read the sticky post concerning this, because this subject has been beaten to death.