And if they use another computer?
And if they use a public computer at, say, a library?

The moon on the one hand, the dawn on the other:
The moon is my sister, the dawn is my brother.
The moon on my left and the dawn on my right.
My brother, good morning: my sister, good night.
-- Hilaire Belloc

Without a login system, the best/only thing to do really would be to just set a cookie with some token that identifies the form information. Whenever someone visits the page check for that cookie and recall the form info associated with the token.

Do not just try and extend the lifetime of your $_SESSION variables by fiddling with it's settings. Set a completely different cookie using setcookie() and check for it in $_COOKIE. Keep $_SESSION for what it's intended, a single session that goes away when the browser closes.

You'll want to provide some method for the user to ignore/erase their existing form and re-fill it if they so choose, to handle situations such as public computers.

I would be wary of anything like this. I would stress to the client that the correct way of handling this would be with people creating an account.

You can get creative with the account creation. Instead of explicitly asking for account info and then asking for them to fill out the questionaire, make the account creation part of the questionaire process, nice and seamless. Dont worry about email confirmation or any of that, make it dead easy to create an account. They will get a heap of spammers create accounts no doubt, but if there is no way they can contribute content to the site, it wont matter.

If there is ANY personal info at all, I would refuse to do it based solely on a cookie on ethical grounds. As much as users may not want to sign up, they will probably value their privacy more than they hate forms.

"Take thy beak from out my heart, and take thy form from off my door" - Homer J Simpson / Edgar Allan Poe

Dont worry about email confirmation or any of that, make it dead easy to create an account. They will get a heap of spammers create accounts no doubt, but if there is no way they can contribute content to the site, it wont matter.

If there is ANY personal info at all, I would refuse to do it based solely on a cookie on ethical grounds. As much as users may not want to sign up, they will probably value their privacy more than they hate forms.

In my opinion, the underlying problem is that you break user expections. Everybody understands a classical registration: You sign up, the server collects your data, and when you log in, you have access to your account. This is simple and intuitive. It's clear that your data gets stored permanently.

Your idea is not intutive. You unaskedly store the data I entered into the form, and when somebody visits the page again, you restore my data. Let's hope the somebody is me and not the next guy in line of the internet café.

I think there's a smarter way of doing this -- like the one suggest by sir_drinxalot. What I would do is try to come up with better alternatives and then simply talk with the customer about potential issues and solutions.

If you have to do it, be aware that you must generate strong random IDs. You don't want people to browse through the form data of all users.

Why can’t I use certain words like "drop" as part of my Security Question answers?
There are certain words used by hackers to try to gain access to systems and manipulate data; therefore, the following words are restricted: "select," "delete," "update," "insert," "drop" and "null".

When I first read this thread the other day, the only reliable way of doing this is by making the user identify themselves first...ie a registration and log in system.

You are trying to be an expert in this field, but you are lacking the diligence required when taking customer requirements on board. It is your responsibility to inform your clients not just about what is and isn't possible but also about the right way of doing things and the legal implications of doing it wrong

Comments on this post

sir_drinxalot agrees

I said I didn't like ORM!!! <?php $this->model->update($this->request->resources[0])->set($this->request->getData())->getData('count'); ?>