 |
|
 |
|
- Readme First! -
Read and follow the rules, otherwise your posts will be closed |
|
|
|
|
|
There are currently, 357 guest(s) and 0 member(s) that are online.
You are Anonymous user. You can register for free by clicking here |
|
|
|
|
|
|
| | The comments are owned by the poster. We aren't responsible for their content. |
| | | | |
| No Comments Allowed for Anonymous, please register | | | | |
Re: Privacy and Cookies (Score: 1)
by forbin on Tuesday, February 10 @ 11:38:37 CET
(User Info | Send a Message) | Disclaimer: I haven't tried this in PHPNuke.
In another web application server, we solved the problem by circumventing the cookie issue entirely. It's not a trivial amount of code, though. :-(
We created a unique identifier for each registered user, and another unique identifier for each current session. Instead of using cookies, we used hidden form fields in the HTML sent to the browser. The contents of the field were an MD5 hash, so users couldn't muck about with it. Our framework code ensured the hidden hash fields were passed back and forth on every HTTP request and response. All of the actual data was stored in a server-side database: both the session data and the persistent user data.
Problem solved.
We could legitimately claim that our site did not use cookies. Our privacy statement said something on the order of "we keep track of only the data necessary for handling user preferences and the accounts of registered users, but we don't use cookie technology to accomplish this." [I am not a lawyer... this is a paraphrase of whatever the legal beagles cooked up.]
I wonder how hard this would be to add to a PHPNuke site? Certainly it's possible to implement in PHP. Could even write a code wrapper so it uses cookies for browser sessions accepting them, and hashed hidden fields for the browser sessions that reject cookies.
Thoughts? Comments? |
| Parent | | | | |
Re: Privacy and Cookies (Score: 1)
by forbin on Tuesday, February 10 @ 11:38:55 CET
(User Info | Send a Message) | Disclaimer: I haven't tried this in PHPNuke.
In another web application server, we solved the problem by circumventing the cookie issue entirely. It's not a trivial amount of code, though. :-(
We created a unique identifier for each registered user, and another unique identifier for each current session. Instead of using cookies, we used hidden form fields in the HTML sent to the browser. The contents of the field were an MD5 hash, so users couldn't muck about with it. Our framework code ensured the hidden hash fields were passed back and forth on every HTTP request and response. All of the actual data was stored in a server-side database: both the session data and the persistent user data.
Problem solved.
We could legitimately claim that our site did not use cookies. Our privacy statement said something on the order of "we keep track of only the data necessary for handling user preferences and the accounts of registered users, but we don't use cookie technology to accomplish this." [I am not a lawyer... this is a paraphrase of whatever the legal beagles cooked up.]
I wonder how hard this would be to add to a PHPNuke site? Certainly it's possible to implement in PHP. Could even write a code wrapper so it uses cookies for browser sessions accepting them, and hashed hidden fields for the browser sessions that reject cookies.
Thoughts? Comments? |
| Parent | | | | | |
|