Convert to function ?

[Tapan]

Hi,

Can this code be converted into an function ?

                foreach ($_POST as $name => $value)
                {
                        switch ($name)
                        {
                                case "btnModNews":
                                        break;
                                case "news_picture":
                                        break;
                                default:
                                        $fields[] = $name;
                                        $values[] = $value;
                        }
                }

Its quite simple code. Taking the $_POST data and putting them in 2 arrays called fields and values. So if i convert it into an function how will i pass the $_POST data to the function ?

function convert ($data)
{
..
..
}

usage:

convert ($_POST) // will this work ?

Thanks.

[crmalibu]

Yes, convert($_POST) would a good way.

You will need to return an array

    return array($fields, $values);
// or
    return array('fields' => $fields, 'values' => $values); 

[Cups]

Not sure what you are trying to do there, but can't you just unset the values you don't want?

unset( $_POST['btnModNews'] ) ;
unset( $_POST['news_picture'] ) ;

and leave the other POST vars as they are?

[lampcms.com]

You don't have to pass the $_POST to convert() function because $_POST is superglobal, meaning its available in every function

this will still work:

function convert ()
{
..
..
}

just use $_POST inside the convert function

[Tapan]

Hi,

I need those, just becuase i don't need the submit button so i am ignoring it and the news_picture is a file field so i have to process it and then add to the fields and values array thats why it is also being ignored.

I will explain in a while what i am trying to do...

Thanks.

[Tapan]

Hi,

That function helps me format the post data so i can use the data to create quick sql queries. I have another function which simply takes the array's in an creates the query and executes it. So i don't have to write a lot of code again and again. Also all my queries are of 1 single line.

When I pass data to query creation function all sql injection checks, filteration etc. is all done at that time, so the data that is inserted into the database is clean. This helps the reduction of overall code and I have created 4 functions called: sqlinsert, sqlupdate, sqldelete and sqlsqlselect.

I have 4-5 projects out of this and all seems to be running pretty fine. In older projects i have used the above code to get post data, but now i'll be using this new function it will make it the code more shorter.

Thanks.

[crmalibu]

Sounds pretty dangerous.

Are you just blindly placing fields and values into an sql query(I know you say you "sanitized" but...)? You should know exactly which fields you need. I get the feeling your just stuffing everything in by how you filter out 2 variables and assume everything else is "good".

What would happen if I were to make my own form and point it at your script, and submit 200 new fields? Or if I used some carefully chosen field names. Think about that.

[Tapan]

Ya its dangerous if there's no login involved but its all protected by login. Also the example you gave of the exploit can be done no matter how you're inserting the data into the sql.

[crmalibu]

Ya its dangerous if there's no login involved but its all protected by login. Also the example you gave of the exploit can be done no matter how you're inserting the data into the sql.

Well, if a logged in user is to be trusted not to do malacious things, and they can be trusted to not let thier browser be tricked into doing malacious things(CSRF attack for example), then yes thats a pretty reasonable assumption.

But no, code which specifically defines which variables it will use will not have it behavior altered if more variables are sent.

[Tapan]

Oh now i see what you mean! Okay ..i am not throwing anything into the database...

My html form fields have the name which the real fields have in the database. So my query builder gets the name of the fields from the html form field's name and its value is stored in that particular field.

So for example if my database table is:

fullname
age
city
dob


then my html form will be:

<form method="post">
<input type="text" name="fullname" />
<input type="text" name="age" />
<input type="text" name="city" />
<input type="text" name="dob" />
<input type="submit" name="Submit" value="Submit" />
</form>

Now the query builder will convert it to like:

INSERT INTO sometable SET
fullname = 'Some Name',
age = '26',
city = 'Some city',
dob = '22 Aug 1986';

Simple! Also is CRSF possible when you're using php sesions ? I have tested it sometime but i was not able to do it. So I am not sure if thats worrying enough.

[crmalibu]

If you know the fields in the database(you do, and should!) then why would you let the request variables define them? Your code should define them.

And yes, csrf attacks are highly possible, and common, when using sessions.

[Cups]

Yes, I see what you are doing now, and I have something similar.

However, there are 2 big differences in my approach.

a) I use (as in composition) PDO so the values are automatically prepared for safer inserting
b) the table column names are checked against a white list of permitted column names

I achieve b) by loading an ini file which serves two purposes, to create the checklist of table columns and to simple form generation and validation.

I have read that you can do b) (generate a white list of permitted column names) by grabbing the database table meta data first.

So I my class picks up something similar to;

first_name-STR-12
tel-INT-9

So the sql generator chucks out messages when I pass it a form containing invalid values.

As in your case this is done in a private login area, and if it detects anything funny, I log the user out. It works very well Ajax.

Maybe that will give you some ideas.

Edit:

... although I would be the first to admit that having to maintain an ini file makes the whole thing less flexible and more brittle.