• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1015
  • Last Modified:

Auto Fill Form (cookies?)

I have an html form that i'm using for customers to fill out information for file uploading. It uses a php script to email the information including submitted files to our store, however, our competator currently has their form automatically fill the whole thing on arrival of the page for the user, which is an ingenious idea and I would like help getting ours set up. I know it's to do with cookies, but I've never used cookies before.

How would I be able to have the form create a cookie on submit so that the next time the user visits, it remembers his name, address, email, phone number etc etc?
0
Arka3L
Asked:
Arka3L
  • 8
  • 6
  • 4
  • +2
3 Solutions
 
ncooCommented:
On your form and submit page, at the top of the page before any code place:

<?php
session_start();
//your code etc..

Then update your form inputs so the value is set from the SESSION value.

echo '<Input type="text" name="user" value="'.$_SESSION['user'].'" />';

Then on your submit page, after the session_start, have something like:

$_SESSION['user'] = htmlspecialchars($_POST['user']);

Repeat this for as many values as you want to autocomplete.

Submit the form once with values and then when you come back to it, it should be already filled in,
0
 
Arka3LAuthor Commented:
When you say submit page do you mean the php script that takes the form variables and emails them?
0
 
Ray PaseurCommented:
This capability uses both Cookies and a Data Base; I do not think the session is directly relevant to the pattern you're describing.  

The cookie is stored on the client browser after they log in.  It contains a key to their identification in the data base.  When a client browser presents the cookie to your script, you can take the key, look up the information from the data base and prepopulate the forms.

Zipbang, easy!
0
Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
Arka3LAuthor Commented:
Ray, as from my last post, you are still referring to making logins. This is not needed and an unnecessary feature for our website. I know that you can make cookies for clients without having to make logins because whenever I go to a form of a website i use regularly I can simply use autofill feature or double click a field and it gives me my list of choices i've used in the past. This is a cookie itself, and our competitor does not use logins either and i've used the form myself.

Ncoo i'll give your idea a try I just wanted to clarify the pages.
0
 
Ray PaseurCommented:
"making logins...." This may just be a point of confusion in the terminology.  Let's try to simplify.  

If you visit a site, and the site has put a cookie on your browser, your browser will send the cookie back to the site on each successive HTTP request.  So far, so good.

Now if you couple that behavior with the idea that you would fill in ANY form on the site, you can fairly quickly see how the site can "remember" you.  There are additional layers of intelligence to this concept. The site can keep a data base record of the pages you visited.  The cookie contains a unique ID that is just associated with your browser.

Note that no "login" is required, per se.  However it is common to respect site visitors privacy by offering them the ability to protect their information with a password.  Once they choose that option, you have created an optional login for those who want it, and all the functionality is still there for those that don't care about privacy.

So can you get by with only a cookie and no login.  Yes, ... Except for just one thing.  If the client accesses your site from a different computer or deletes their cookies, you have lost the only connection you had with them.  That makes a fairly strong case for a login, IMHO.
0
 
VanHackmanCommented:

Hello Arka3L,

Honestly I can't suggest you use Cookies to implement some "Auto Fill" function, because as you must know, cookies are stored on the client, and this mean that you will lost some control over the data integrity, there are a lot of ways to modify the information stored in cookies, and use them to identify users and "Auto Load" information like name, address, email, phone number is create a BIG HOLE in your application security even more if you are planning store the data directly in the cookie!!!...

The method proposed by ncoo will not be a persistent solutions, because the information will be available to "Auto Fill" the form only while the session is active, when the session expire the information will be unavailable, any way is a better way that the method proposed by Ray:

"When a client browser presents the cookie to your script, you can take the key, look up the information from the data base and prepopulate the forms."

How you can be sure that no one modify the cookies?... Have you ever been hear about "Stealing Cookies Methods"? No?... just read: http://jehiah.cz/archive/xss-stealing-cookies-101

Tell me... Do you already have a user Identification/Management System on your application?
I mean, when you say "our competitor" make me thing that you are trying to improve a private system/application.

So... If you already have a user Identification/Management System, use it to identify the users in your site!!, store the user information in your DB and after that implement a "Auto Fill Form" will be very easy.

If your application doesn't have a user Identification/Management System, well... I suggest you implement it, but if you don't want, use the sessions method, suggested by ncoo, will be a "Safer" solution.


0
 
ncooCommented:
> When you say submit page do you mean the php script that takes the form variables and emails them?

Yes that's the page..

0
 
Arka3LAuthor Commented:
What I want you guys to understand is that this information is simply point of contact details ,it's not credit cards, it's not really "personal" information, it's just a method that we can use to keep in contact with some clients. We're a Reprographics company, so that means we basically do a lot of large and small format printing for day to day people needing copies to construction companies needing blue prints.

I wanted to try and keep this as simple as I could since I'm not a qualified programmer :) Our host allows us to setup Mysql through the control panel, but unless there is a zip file i could download and setup in minutes with all of the working files for registering accounts and forgot passwords etc etc, then there's really not much point, because if anything, it's just a small inconvenience.

And if what ncoo suggested is just session only, then it doesn't help me.
0
 
Ray PaseurCommented:
@VanHackman: There is no design pattern I know of that would place meaningful information in a cookie.  The cookie is like a key to a record in the data base, and you never put meaningful information into a key.  Comp Sci 101.

I think our asker has to strike a business balance between security and convenience.  I know that many successful e-commerce sites do what he is describing, and I know how they do it - just as I described above.  Here is why they do it.

1. It is unobtusive - this seems to be one of Arka3L's important issues.  He does not want to make his clients log in.

2. It is easier to convert a sale if the site remembers what the client put in the cart, or whatever other information the client provided to the site.  Nobody likes to have to type the same stuff over and over again.

3. It is 100% safe and secure because you DO NOT STORE critical information in the data base records that are accessible through the cookie-only method.  The risk of stealing cookies only occurs if you do it wrong, and rely on the cookie without verification.

4. At some level, it does not matter if the cookie is modified (or lost) because the only thing that will happen is that the client will have become a "stranger" - this is not desirable, but it presents no risk of harm to the web site or the underlying data model.

Anyway, if the only cookie you use is the session cookie, then the only persistence you will have is the duration of the browser window, and that does not seem like much of a "memory" to me.

best to all, ~Ray
0
 
ncooCommented:
> Login

Using a login will have benefits as Ray_Paseur has suggested and means the information can be kept indefinitely and accessed from multiple browsers. It might be something to look into, it might make your site better then the competition but only you know your market.

> Sessions and Cookies

They will expire, or the user will clear the cache at some point. Using a Session to store user details is more secure then Cookies.

> Cookie and DataBase

The cookie could be deleted and can only be accessed from one browser. The data is secure though and perhaps a better alternative to keeping Sessions open for X days, instead you'r only storing a Cookier for X days which points to a Database record.

This will involve more work then a Session, but should you move over to the login in the future half the work is already done.

If your Cookie contains a Record ID a user could alter the value as VanHackman has suggested and autofill the form with someone elses data.


Perhaps something else to consider is lifetime of the data, do you want the data to expire?
0
 
Ray PaseurCommented:
"... I'm not a qualified programmer :)"

I understand, and you might want to consider getting a professional involved.  Cookie handling and data base work are not intuitively easy.  I would be glad to show you how cookies work - you can see that in the code snippet.  This is a teaching sample - you can install it and run it on your server, but it is not suitable for use in your application.  Hooking the other parts together is the business logic that would be unique to your business needs and competitive requirements.
<?php // RAY_cookie_example.php

// RECEIVE FORM INPUT AND SET A COOKIE WITH THE NAME AND VALUES FROM THE FORM
// MAN PAGE: http://us.php.net/manual/en/function.setcookie.php
// TO SEE COOKIES IN FIREFOX, FOLLOW TOOLS => OPTIONS => PRIVACY => SHOW COOKIES

define('COOKIE_LIFE', 60*60*24); // A 24-HOUR DAY IN SECONDS ( = 86,400 )

if (!empty($_POST)) // IF THE FORM HAS BEEN POSTED
{

// TIDY UP THE POST INPUT - CLEAN AND NOT MORE THAN 16 BYTES
   $name = substr(clean_string($_POST["name"]),0,16);
   $data = substr(clean_string($_POST["data"]),0,16);

// BE SURE WE HAVE USEFUL INFORMATION
   if ( ($name == '') || ($data == '') ) die("MISSING INPUT: PLEASE <a href=\"$PHP_SELF\">TRY AGAIN</a>");


// CHOOSE THE COOKIE NAME AND VALUE
   $cookie_name    = $name;
   $cookie_value   = $data;



// ESTABLISH THE COOKIE LIFE - CHOOSE ONE OF THESE FOR THE COOKIE
// USE THIS TO MAKE COOKIE EXPIRE AT END OF BROWSER LIFE
   $cookie_expires = 0;

// USE THIS TO MAKE A PERSISTENT COOKIE - DEFINE COOKIE_LIFE IN SECONDS - date('Z') IS UTC OFFSET IN SECONDS
   $cookie_expires = time() + date('Z') + 30 * 60 * 60 * 24;



// ESTABLISH THE COOKIE DOMAIN SCOPE - CHOOSE ONE OF THESE FOR THE COOKIE
// MAKE THE COOKIE AVAILABLE TO ALL DIRECTORY PATHS IN THE WWW ROOT
   $cookie_path	= '/';

// MAKE THE COOKIE AVAILABLE TO ALL SUBDOMAINS - DOMAIN NAME STARTS WITH DOT AND OMITS WWW (OR OTHER SUBDOMAINS).
   $x = explode('.', strtolower($_SERVER["HTTP_HOST"]));
   $y = count($x);
   if ($y == 1) // MAYBE 'localhost'?
   {
      $cookie_domain = $x[0];
   } else // SOMETHING LIKE 'www2.atf70.whitehouse.gov'?
   {
// USE THE LAST TWO POSITIONS TO MAKE THE HOST DOMAIN
      $cookie_domain = '.' . $x[$y-2] . '.' . $x[$y-1];
   }



// MAKE THE COOKIE AVAILABLE TO HTTP, NOT JUST HTTPS
   $cookie_secure    = FALSE;



// HIDE COOKIE FROM JAVASCRIPT (PHP 5.2+)
   $cookie_http      = TRUE;



// SET THE COOKIE
   if (setcookie($cookie_name, $cookie_value, $cookie_expires, $cookie_path, $cookie_domain, $cookie_secure, $cookie_http))
   {
      echo "<br/>SUCCESS!  THE COOKIE HAS BEEN SET AND WILL BE AVAILABLE TO THE NEXT PAGE LOAD \n";
   }
   else
   {
      echo "<br/>FAILURE!  THE COOKIE WAS NOT SET AS EXPECTED \n";
   }



// AT THIS POINT, THE COOKIE HAS BEEN SET, BUT IT IS _NOT_ AVAILABLE TO THIS SCRIPT.
// THE COOKIE WILL NOT BE AVAILABLE TO OUR SERVER UNTIL THE NEXT SCRIPT!
// THIS IS BECAUSE THE BROWSER SENDS THE COOKIE TO OUR SCRIPT BEFORE OUR SCRIPT STARTS RUNNING.
// HOWEVER THE $_COOKIE ARRAY IS NOT IMMUTABLE, AND WE CAN ADD INFORMATION TO IT
// IF WE WANT TO USE IT IN THIS SCRIPT.  THIS IS PROBABLY A BAD PROGRAMMING PRACTICE
   echo '<pre>$_COOKIE CONTAINS '; var_dump($_COOKIE); echo "</pre>\n";
   echo '<pre>$_POST CONTAINS ';   var_dump($_POST);   echo "</pre>\n";
   echo "<br/>THE COOKIE HAS BEEN SET WITH THESE VALUES: \n";
   echo "<br/>COOKIE NAME: $cookie_name \n";
   echo "<br/>COOKIE VALUE: $cookie_value \n";
   echo "<br/>COOKIE EXPIRES: $cookie_expires ";
   echo " == " . date('r') . "\n";
   echo "<br/>COOKIE PATH: $cookie_path \n";
   echo "<br/>COOKIE DOMAIN: $cookie_domain \n";
   echo "<br/>COOKIE SECURE: "; var_dump($cookie_secure); echo " \n";
   echo "<br/>COOKIE HTTP: ";   var_dump($cookie_http);   echo " \n";

   echo "<br/>";
   echo "<br/>TO SEE THE COOKIES, IF ANY, <a href=\"{$_SERVER['PHP_SELF']}\">CLICK HERE</a> \n";
   echo "<br/>";
}

// END OF SETTING THE COOKIE
?>


<form method="post">
COOKIE NAME: <input name="name" /><br/>
COOKIE DATA: <input name="data" /><br/>
<input type="submit" />
</form>


<?php
// SHOW THE COOKIE ARRAY, IF ANY
echo '<pre>$_COOKIE CONTAINS '; var_dump($_COOKIE); echo "</pre>\n";



// A FUNCTION TO FORCE A STRING TO CHARACTERS ONLY
function clean_string($string)
{
   return trim(preg_replace('/[^A-Z0-9_]/i', '', $string));
}
?>

Open in new window

0
 
Ray PaseurCommented:
"Using a Session to store user details is more secure then Cookies." - I do not agree with that.

Sessions almost always use cookies.  The session cookie points to a temp file on the server.  The temp file contains the information that is put into the $_SESSION array.

Contrast that to a persistent cookie that points to a row of a data base table.

Where is the difference in the "security" of these two approaches?  If there is ANY material difference in security it would mean that the application is incompetently designed.  Both use an external key, stored on a client machine, as a pointer to data that is held on the server.  In fact, data base driven session handlers are common design patterns.  

The central difference between the two approaches is the persistence of the cookie.  The session cookie, by definition, expires at the end of browser live.  The persistent cookie enables a longer memory since the application sets the cookie to the life that most closely matches the business requirements.
0
 
ncooCommented:
> "Using a Session to store user details is more secure then Cookies." - I do not agree with that.

I was referring to the use of

$_COOKIE['ADDRESS'] = '123 Street';

vs

$_SESSION['ADDRESS'] = '123 Street';

With the former the address details are sent with every request to the website, where as with the session only the session id is sent.

But then again if someones is listening in they can get the SESSION ID or Persistent Cookie, which means SSL should really be used. For the application as described SSL would probably be over the top.

> The central difference between the two approaches is the persistence of the cookie.  The session cookie, by definition, expires at the end of browser live.  The persistent cookie enables a longer memory since the application sets the cookie to the life that most closely matches the business requirements.

I would agree with that, it does come down to how long the data should persist as to which solution is most appropriate.
0
 
Ray PaseurCommented:
$_COOKIE['ADDRESS'] = '123 Street';

That would get you fired in my company, or get you an F in computer science, and that is why we would never use such a design pattern.  The correct analogy is Session contents and Data base contents.  The cookie is only a pointer, not an information store.

The "real" information is always stored on the server, full stop.  The pointer is known to be unsecure and cannot be used for any purpose that changes the data model, until after the client has self-identified and has been authenticated.  This latter step often takes place in a checkout algorithm, where SSL and authentication make a lot of sense.
0
 
Arka3LAuthor Commented:
I appreciate everyones responses, I haven't had a chance to read them yet because it's been real hectic at work, so don't worry, i'll respond soon.

Thanks again.
0
 
Ray PaseurCommented:
12/22/09 12:53 PM, ID: 26106683 - Description of the concept
12/22/09 01:36 PM, ID: 26107045 - Further explanation
12/22/09 01:52 PM, ID: 26107189 - Programming example of how to handle cookies
0
 
Arka3LAuthor Commented:
Ray, and Angel, I apologize for not testing this out fully, i've been responsible for implementing a new software for the company and have been working like a dog to get it up and running, I'm not sure when I'll have the time to worry about our cookies idea for a while. I'd like to keep this open for late but I don't want it just sitting around. Any chance this can be suspended until I give further notice?
0
 
Guy Hengel [angelIII / a3]Billing EngineerCommented:
>Any chance this can be suspended until I give further notice?
you cannot get EE questions "suspended" for long...
please find some spare time :)
a3
0
 
Ray PaseurCommented:
"please find some spare time :)" - yeah, and if you find much of it, send me some!

One way to handle issues like this is with a bookmark.  Then it is easy to refer back.   Just a thought. ~Ray
0
 
Arka3LAuthor Commented:
Sorry guys,

Angel feel free to award Ray the points but this question wasn't fully resolved so don't archive it.
0

Featured Post

Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

  • 8
  • 6
  • 4
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now