• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
best practice with form,validation,error,success,action order

#21
[eluser]ssjcory[/eluser]
While javascript sucks. I use it to validate my forms... Then when it hits my php code I do something like this:
// Retrieves a user from session
$User = new User();
if (!$User->isLoggedIn()) {
header('login.php');
}

$User->getUserInput($_POST);
$User->setValidationRules($Form->getValidationRules());
if (!$User->Validation) {
header('failurl.php');
}


At least thats how I think it could be done nicely.
Hope this helps,
Cory

#22
[eluser]Michael Wales[/eluser]
sikkle - the only reason I was encrypting that field was to show, for a fact, that the strings were all returning the same.

If you md5 these two strings: "mystring" and " mystring " you would receive different results, because of the spaces.

So, no - you don't want to encrypt every field, just the important ones - I was only doing it to show the similarity more easily.

#23
[eluser]ssjcory[/eluser]
I forgot encryption. Our database encrypts data when it comes in :-) Code level encryption is tedious for big projects.
-Cory

#24
[eluser]BravoAlpha[/eluser]
[quote author="walesmd" date="1187724029"]I guess my point was simply: you can access the input a variety of methods. $this->input->post is not the only way, especially if using $_POST is going to save you 6 lines of typing. In the end, they all come out to exactly the same thing.[/quote]
I don't think you should dump $_POST into the database; You don't know what's in there.

Let's say you have a user table that contains ids, name, email addresses, passwords, and some kind of permission field. If you have an update form that allows users to change their email and password (etc.), then dumping $_POST in should work fine. However, if a user also managed to include $_POST['permission'] in their form (e.g. they made their own form, or used curl locally, etc.), then that user's permission field would also be updated when you dump $_POST into the database, and that user would now have permission on your site that he shouldn't have.

#25
[eluser]ssjcory[/eluser]
Thats why you must validate it. Also in validation you should also be running cross site scripting defense mechanisms. Stripping out invalid/illegal characters.
-Cory

#26
[eluser]sikkle[/eluser]
walesmd : thanks for the clarification. I didn't do the good analyse on the first shoot. my bad.

ssjcory : what is your reason to choose javascript validation and not php one ?

#27
[eluser]ssjcory[/eluser]
I do validation in javascript and php. Javascript validation i do more for the customer so that they dont have to wait for the page to load for it to say hey u screwed up. If somehow javascript validation doesnt get everything my php validation certainly does.
-Cory

#28
[eluser]Michael Wales[/eluser]
Quote:Let’s say you have a user table that contains ids, name, email addresses, passwords, and some kind of permission field. If you have an update form that allows users to change their email and password (etc.), then dumping $_POST in should work fine. However, if a user also managed to include $_POST[’permission’] in their form (e.g. they made their own form, or used curl locally, etc.), then that user’s permission field would also be updated when you dump $_POST into the database, and that user would now have permission on your site that he shouldn’t have.

Good point - which is why we stress validation to those asking these questions. Not only should you validate the data coming in, but validating the source of the data is always a good idea as well.

#29
[eluser]Unknown[/eluser]
Seems to be a very convincing reply...

thanks for the info..Smile. you all do have some good sense of humour too.... :cheese:


Digg   Delicious   Reddit   Facebook   Twitter   StumbleUpon  


  Theme © 2014 iAndrew  
Powered By MyBB, © 2002-2020 MyBB Group.