Jump to content

If statement comparing value of fetched associative array to value of POST passed variable incorrectly determining order of operation

Go to solution Solved by mac_gyver,

Recommended Posts

Okay, here is the required information:

  • Apache/2.2.22 (Ubuntu)
  • MySQL client version: 5.5.34
  • PHP extension: mysqli

Here are the three raw sql statements, using sample data.
Statement 1: 

SELECT uuid FROM EmptyCart WHERE uuid = '52b6392b-c55f-71ef-2437-c0645d3d5ea0'

Statement 2: 

UPDATE EmptyCart SET fname="so", lname="this", company="should", address="insert", city="", state="", zip="", phone="", country="US", cart_coupon="", email="", orderSubTotal="46.15", orderTotal="46.15", numOfItems="2", items="a:2:{i:0;s:5:item1;i:1;s:5:item2;}", ids="a:2:{i:0;s:3:id1;i:1;s:3:id2;}", codes="a:2:{i:0;s:5:code1;i:1;s:5:code2;}", qtys="a:2:{i:0;s:1:1;i:1;s:1:1;}", price="a:2:{i:0;s:5:44.95;i:1;s:3:1.2;}", orderTax="0", orderShipping="0", appliedPromoIdList="", coupon="", storeId="storeid", activeShipPromotionCount="", itemImages="a:2:{i:0;s:6:image1;i:1;s:6:image2;}", date="Mon Dec 02 2013 13:40:38 GMT-0500 (Eastern Standard Time)" WHERE uuid='52b6392b-c55f-71ef-2437-c0645d3d5ea0'

Statement 3: 

INSERT INTO EmptyCart (uuid,fname,lname,company,address,city,state,zip,phone,country,cart_coupon,email,orderSubTotal,orderTotal,numOfItems,items,ids,codes,qtys,price,orderTax,orderShipping,appliedPromoIdList,coupon,storeId,activeShipPromotionCount,itemImages,date) VALUES ("52b6392b-c55f-71ef-2437-c0645d3d5ea0","so","this","should","insert","","","","","US","","","46.15","46.15","2","a:2:{i:0;s:5:item1;i:1;s:5:item2;}","a:2:{i:0;s:3:id1;i:1;s:3:id2;}","a:2:{i:0;s:5:code1;i:1;s:5:code2;}","a:2:{i:0;s:1:1;i:1;s:1:1;}","a:2:{i:0;s:5:44.95;i:1;s:3:1.2;}","0","0","","","storeid","","a:2:{i:0;s:6:image1;i:1;s:6:image2;}","Mon Dec 02 2013 13:40:38 GMT-0500 (Eastern Standard Time)")

No errors are being returned, in fact, the queries all work fine.


What is happening is actually within the PHP, however I have included the SQL statements as they may be causing the logic errors in the PHP code operation.


Here is the section of PHP code where the error is happening:

$prequery = mysqli_query($con,"SELECT uuid FROM ".$mysql_table." WHERE uuid = '".$tablevalues[0]."'");
$tango = $prequery->fetch_assoc();
if ($tango["uuid"]=$tablevalues[0]) {
$new_count = count($tablefields);
$mysql_update = "";
for ($z=1;$z<$new_count-1;$z++){
	$mysql_update .= $tablefields[$z]."=".$tablevalues[$z].", ";
$mysql_update .= $tablefields[27]."=".$tablevalues[27];

$sql = "UPDATE ".$mysql_table." SET ".$mysql_update." WHERE uuid='".$tango["uuid"]."'";
} else {
$sql = "INSERT INTO {$mysql_table} ({$tablefields_implode}) VALUES ({$tablevalues_implode})";
// pprint_r($sql);


The Correct Functionality should be:


On the client-side, a new user visits the page the form resides on and begins filling out the form. Upon initial visit, a unique identifier is assigned to the user and stored in localstorage.

Every time a form field is updated/changed the value is stored in localstorage.

Every 30 seconds, selected contents of the form data (as pulled from localstorage) are sent to our server database via Ajax POST.

The PHP Processing file receives the POST data and performs a series of SQL injection prevention functions on the data.

The PHP file constructs a new array of cleaned data and uses that data array to construct the mysqli queries above.


What should happen is the unique identifier should be checked against existing database entries and if it exists the relevant entry should be updated. If the unique identifier does not exist, a new entry is made.


What is currently happening:

Every incoming POST is evaluated and results in an UPDATE statement, even if the unique identifier does not exist in the database.


Things I have tried:

I have tried changing the value of the request for $prequery to reference a variable established earlier in the processing, but the result was the same. The code selects from the database and is still somehow evaluating that nothing = something.



The first SQL statement, the select one, is the reason for the change of the variable to one earlier in the array processing. The value of the variable was being displayed with double quotes around it and breaking the SQL statement, however even with the new variable that does not have the double quotes the operation is still resulting in an Update instead of Insert despite the uuid not being in the database.

Edited by Will_Case
Link to comment
Share on other sites

That worked for getting the code to identify that there was not an entry in the database already matching the unique identifier, however it is still evaluating the processing incorrectly and does not update the database. Every time the form posts the PHP evaluates and is now inserting.


Basically, I applied the update you suggested and the returned data indicated the change in the $sql statement, however waiting another 30 seconds for what should have been an update instead showed another insertion. A check of the database shows duplicate entries.




The solution is the same solution I had to do for the mysqli_query.




Was being evaluated as data=="data"


By changing the $tablevalues[0] to the earlier variable of the same data (prior to applying the double quotes for the prepared statement) it now triggers the UPDATE statement.

Edited by Will_Case
Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • 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.