encoding cookie content
 

I want to accomplish a shopping cart that is storing its content in the database and setting a cookie.
This cookie needs to be refered to the shopping cart, even if the visitor comes back the orginal shoppingcart still excist just like Amazon, so a php session_id is not the best solution?
The question is, what values needs the cookie to be? I can set the shooping cart ID, only that is not really safe. It needs to be encoded somehow. Someone good advise about the smartest/safest solution?

Well, the only good ways to encode a string, is first to put it in an array. Then you can serialise() it and then write it into the cookie, which can be decoded with unserialise(). If you prefer NOT to use an array but a string, you should first urlencode() it and then base64_encode(). Both can decoded again with their opposite functions called urldecode() and base64_decode().

I hope this helps you out.

Everything will be stored on the server, I only need to identify the visitor each time. So I only need to have a ID in the cookie, but that is not safe because, of the cookie manipulation. So I can encode it, but base64 is also not a good idea because still everyone can encode/decode it and manipulate the cookie.

I also can generate a unique string in the database and use that as an cookievalue.
But why not generating a unique string with the ID or something else, so I can decode it back to the ID. But what is a good method? Maybe blowfish?

You can create your own "encryption algorithm", for example:
new_cartID = cartID * 13 + 7

Then to reverse back the number:
old_cartID = (new_cartID - 7) / 13

After creating the new cartID you could base64 encode it to store it in the cookie.
This example is too simple, but if your cartID was 10, the new_cartID would be 137. If you base64 encode 137 you get MTM3. A smart guy trying to manipulate the cookie could base64 decode it back to 137.. but he doesn't know that 137 is not the real cartID.

This method won't eliminate the possibility of a person seeing the cart of another. If the smart guy changes his cookie to MTI0, your PHP script will decode it to 124, then convert 124 to 9 [(124-7)/13].. which could be a valid cartID of another customer.

If you really want security then you should look for encryption algorithms like blowfish, aes, des, RC4.

RC4 is very simple, yet powerfull, and should do the job for you.
You provide a password/key and the data and it returns the encrypted data, the only way to decrypt it is to RC4 it again using the same password/key. There are a lot of RC4 classes available for download, like this one.

Session IDs are secure. You just have to look at possible session ID downfalls in terms of security. Obviously for the session ID that determines whether or not they have access to their account, that has to be a long and complex session ID that is unlikely to be guessed. Whereas for a shopping cart, I wouldn't even say that has to be that long and complex -- after all, if I somehow guess your session ID, what will I get? Your shopping list, and nothing more. I won't even know who you are and so I can't be your wife checking up on how many other women you bought presents for!

My concern about session ID is, that I need to store it in a database for checking if the returning visitor has created a shopping cart before.

How can I link an session_id that is created before and excists in a custom cookie to a new session?

You can use the session_id() function to change the id of the current session.

Hey man,
You could generate some long random string or number, which you use as session ID. So, you store this string, as it is, in your db, and put that string, encrypted with xor algorithm, in cookie. You can use user ip address, as encryption key, so, when you see that user has that cookie set to some value, you decrypt it using that user ip, and if everything is ok, you'll get real session ID.

the only advantage of this method, compared to standard php session, is that that session id is attached to ip, so, if "hacker" will steal that session ID to do some filthy things, he wount be able to do this from another computer(if, ofcourse, he does not know about your implementation of sessionID encryption)

and sorry for my ugly English :)