Jump to content


Staff Alumni
  • Content Count

  • Joined

  • Days Won


mac_gyver last won the day on July 21

mac_gyver had the most liked content!

Community Reputation

454 Excellent


About mac_gyver

  • Rank
    Staff Alumni

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

147,132 profile views
  1. since the code is un-setting the variable and will always output 'else test', if you are not seeing the output, ether - your code is redirecting all over or using ajax to display content and you are not actually 'on' the page where this code is at, but the refresh does 'goto' the page where this code is at. you have some conditional logic that is preventing the posted code from being executed, either explicate logic or an exit/die statement, which the refresh doesn't trigger, and so the posted code gets executed. some html is being conditionally output prior to the posted code and the output from the posted code is hidden in the 'view source' of the page, but, again, the refresh doesn't trigger the prior output, and so you see the output from the posted code. since you have repeated the unset() statement with the variations of the code, i/we assume that is actually part of this code. do you understand what the unset() statement does and what affect it will have on the conditional logic test(s) you have posted? as stated on one of the other help forums, all you are showing/describing are snippets of code and symptoms. if you just post all the relevant code for the page(s) involved with this problem, someone can probably solve this in a couple of minutes.
  2. use the PDO extension, use exceptions for errors and in most cases let php catch and handle the exception, and use prepared queries when supplying external/unknown data to the sql query. this will result in the simplest and most consistent code. if the scope of your work is limited to just getting the database code to securely work, you would write user functions that use the PDO extension internally, then search/replace the mysql_xxxx functions with the new user written pdo_xxxx functions. for the new pdo_query() function, it would have an optional call-time array parameter for the prepared query input data. if this input parameter is empty, the function code would just call the query method. if the input parameter is not empty, the function code would first call the prepare method, then supply the array of input data when it calls the execute method. for any query that has external/unknown data being put directly into it, you would need to convert it to be a prepared query by removing the variables, any quotes around the variables, any {} around the variables, and any concatenation dots, and replace each value with just a ? place-holder. the variables that got removed would be supplied as the array call-time parameter to the pdo_query() function call. if any of the queries are being dynamically built, you will need to address changing them to be prepared queries on a case by case basis. of concern are the number of files you have. this typically indicates that the code is not general purpose and could stand to be re-factored to use a content management system (CMS) and a data driven design. perhaps something to budget time for in the future?
  3. how did you arrive at this point? did this code work before? did you copy/paste the PASSWORD_BCRYPT value from somewhere or did you type it manually? if you copied it, i recommend that you delete it and manually type it. we have seen cases where 'published' code contains non-ascii or non-printing characters, which looks correct, but which php cannot recognize.
  4. if php can read it to load it, you can read it to make a copy - <?php $in_file = 'C:\xampp\php\php.ini'; // path to the php.ini, can be found in the phpinfo() output under - Loaded Configuration File $out_file = 'ini.org'; file_put_contents($out_file,file_get_contents($in_file));
  5. it takes more than just converting the database statements to update old code. due to the removal of magic_quotes, that provided some security in external string data, you must add protection against sql special characters in data from breaking the sql query syntax, which is how sql injection is accomplished. if you have a large amount of code that needs to be updated, creating user written functions that use the PDO extension internally to replace the mysql_ functions, via search/replace, then change any query with external data being put directly into it, into a prepared query, will result in the least amount of overall changes to the code. if you only have a small amount of code that needs to be updated, just directly re-writing it to use the PDO extension is the best solution. while you are making these changes, switch to use exceptions of errors and in most cases let php catch and handle the exception, where it will use its error related settings to control what happens with the actual error information (database errors will get displayed or logged the same as php errors.) this will let you eliminate, rather than convert, the existing error handling, which is only giving real visitors information they cannot do anything about, and giving hackers useful feedback that something they did caused a specific type of error.
  6. the error is because there are a different number of place-holders in an sql query statement compared with the number of values supplied when the query is executed. the solution would be to find out why that is happening and correct it. it's likely that the computer restart as part of the win update either committed or lost some unsaved change in a server setting or in a code file.
  7. probably because the code is assigning a 1 to the session variable. your code should - unconditionally start the session, in a common 'required' configuration/initialization file. first detect if there is a logged in user. if there's not a logged in user, there's no point in querying to get any user data. you should instead set up a default set of $user data. if there is a logged in user, run the query to get the user's data. you should only SELECT the columns you want, and unless this is part of a login script, you should not SELECT the password hash. if the query didn't find any matching user data, you either have a programming mistake or a user's row got deleted between the time the user logged in and when you executed this query. if the query did find matching user data, fetch it to replace the default values set in item #2.
  8. the posted code contains some problems and questionable logic that need to be corrected before you worry about making changes to what it is doing - to display a product, a commented out 'avail' value, an image, and a price are being checked in the code. this should be done in the sql query. you should only query for products that should be displayed. in the case of having an image and a price, should the product even have been INSERTed if these pieces of data weren't submitted? the html table 'cleanup' code needs to be inside the end of the if($result) logic and also needs to output a closing </tr> tag. there are several 'empty' <a> anchor/link tags being produced. why? the non-empty <a> tag that starts with the product image is never closed. should this even be a link and what portion of the product information should it include? if there's no item no and description for a product, do you really have a product to display? these two values are being put into the paypal form data. do you want empty values for them to be submitted to paypal? for your added conditional logic, if there are only two choices, a zero or a one, you only need - if(expression) { logic for a true expression } else { logic for a false expression}
  9. i reviewed one of your earlier threads and it was using an array to hold errors. what happened, why did you take a step backwards? your existing validation logic for a 'required' field is not doing what you think, so, when you copied it for a non-required field, it has no chance of working. for a required field, if the input is empty, that's an error and there's no point in running any additional validation on that input as they will fail too. only if the input is not empty, run additional validation on that input. the logic to do this would look like - if(some required field == '') // note the comparision is with an emtpy string. php's empty() treats a zero as empty, so if zero is a valid value, you don't want to use empty() to test it. { // the field is an empty string $errors['some field name'] = "This field is required."; } else { // the field is not empty, perform additional validation step(s) if(!some other validation test) // note the ! (not) in the conditional statement { // the field did not pass this validtion test $errors['some field name'] = "This field does not meet the requirements of this validtion test."; } } for a non-required field, you don't care if the field is empty, but if it is not empty, you perform the additional validation (this is basically the else logic from above) - if(some field != '') { // the field is not empty, perform additional validation step(s) if(!some other validation test) // note the ! (not) in the conditional statement { // the field did not pass this validtion test $errors['some field name'] = "This field does not meet the requirements of this validtion test."; } } if all you are doing with preg_match is finding if a value matches the pattern, there's no need for the matches parameter. just directly test the result of the preg_match statement. your original validation logic for the account field contained miss-typed variables and incorrect preg_match parameters. do you have php's error_reporting set to E_ALL and display_errors set to ON so that php would help you by reporting and displaying all the errors it detects? lastly, when you have more than about 2-3 form fields, you should dynamically process the form data, by defining an array that holds a definition of the fields and what validation tests to perform on each field. this is a level to work toward in your coding, so that you don't find yourself writing out bespoke logic for each form field for each different form.
  10. this code is repetitive and has a number of logical mistakes. there are two different current 'owner' (uploaded) user ids, in $user->id and in $pt->user->id. the code querying for the video transaction data is getting data for all dates, but the code querying for the ad transactions is getting data for just a range of dates, so the sum of the amounts from those two things is meaningless. the code getting the $user_data, which, based on the usage, is the purchaser, is using the transaction id, not the user_id. the code is already looping over the video transactions for the current logged in user. the query and loop you just added is looping over the video transactions again, but is using some pieces of data from the outer loop, in $tr, which is why the amount and date are not changing. get rid of the query and loop you just added and use the data you already have (after you fix it so that it gets the $user_data based on the user_id and not the transaction id.) what order do you want the data to be in? the video transaction query is currently ordering the video transaction data by the user_id, which makes no sense, but the currently displayed id values are the video ids. this code/queries are doing what they were written to do, mistakes and all. it's up the programmer writing the code/queries to define what he/she wants, before writing anything, then design, write, test, and debug the code/queries to make sure they are doing what was defined.
  11. how about the letter-case and any white-space between the value in the php code/error message and the actual path and filename? any chance the php version was changed recently? if you change the statement from require_once to require, does it work?
  12. form processing code should - detect that a post method form was submitted. trim all input data (this can be done with one statement), so that you can detect if all white-space characters were entered. this is the only 'modification' of the form data that should be done. if there can be more than one form, you need some control logic (switch/case statement is one way) to detect a unique value (hidden field) to control which form processing code gets executed. the validation logic needs to store the validation errors in an array, with the array's main index being the field name (this index is used for 'dependent' validation steps to let you test if there is or is not already an error for a field and if you are outputting the error near the form field it applies to.) this array is also an error flag. if the array is empty, there are no errors, if the array is not empty, there are errors. if there are more than about 2-3 form fields, you should dynamically validate and process the form data, by defining a data structure (array or database table) that contains elements for each field that control what general purpose code does, such as defining 'required' fields, what type of validation rules to apply, and which type of processing code the field is used in. after the validation logic, if there are no errors, use the submitted data for whatever purpose it is intended for. after the data has been used, if there are no errors, perform a redirect to the exact same URL of the form processing code to cause a get request for the page. if there are errors, the code continues and re-displays the form, with any error messages (either all at once or with each one near the field it applies to), and repopulate the (appropriate) fields with the previously submitted data values (applying htmlentities() to help prevent cross site scripting), so that the user doesn't need to keep reentering the same data.
  13. the path being used in the opendir() statement either has a hard-coded '/home/sites/' in it or is using a variable that has that incorrect value in it. based on the path where the code is actually at, that part of the path should be - /home/customer/www/
  14. please post your final code. a lot of beginners end up with 'working' code, that isn't actually secure or contains a lot of unnecessary statements, variables, and php/sql syntax.
  15. yes, but that's the message you or someone else is unconditionally echoing inside the form processing code. it means that the form processing code executed. echo "Check Required Fields";
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.