thanks a lot :-)

using the users remote IP is a bad idea because many users sit behind a NAT-Gateway.

Best regards
Jean Marie

* If you’re primarily using the data server side, it would be better to simply store it in a session. Otherwise, while you’re protected from tampering you’re still open to sniffing of sensitive data and hijacking of cookies.

* Tying it to the user id only helps so much, as the user id won’t be present until the session is already loaded. This would, from the perspective of the hackers, just make the hash another session id. If they can steal the session (and take on the user ID) they’ll be able to steal the other cookies as well.

* If someone logs out all of their cookies are invalidated- this may be intentional, but if you want data tied to a session it should be in the session.

* If you’re using the data client side (javascript) you’re only going to have read only access.

That being said, I really should have touched on this subject, as there are definite cases where it would be useful. Thank you for fixing that discrepancy on my part.

I definitely understand what you’re saying though, and will keep it in mind for future posts (I am still rather new at this).

// To “encode”
$id = 232; // ID to a database record, for instance
$my_secret = md5( “Some secret, eh?” );
$checksum = md5( md5( $id ) . $my_secret );

// To decode:
list( $id, $checksum ) = explode( “-”, $_COOKIE['the_cookie'] );
$my_secret = md5( “Some secret, eh?” );
if ( md5( md5( $id ) . $my_secret ) != $checksum )
{
die( “Tampering detected” );
}

In the database you can store whatever you want.