* Thus wrote John Manko ([EMAIL PROTECTED]): > I'm having a little trouble understanding how to accomplish this. > Should the entire browsing session be HTTPS after login, or just for > important functions like "login" and "checkout" > If noly for those function, who should I design to jump back an forth. > I know DB should be used for cart items, but when I jump to HTTPS, > should I enclude the session ID (which will be stored in the DB) as a > GET query string field? If not, how else will I be able to know which > user to continue with. I don't see any functions that will let you > specify which session ID to continue with. What is the best practice?
It is overkill to run whole site on https, you only need it when sensitive data is being sent back and forth (ie, credit card, login info..) Technically you only need to use https when the user actually submits the form to the script that processes. So the page that generates the form for the user to login does NOT need to be encrypted, the forms action will contain the https url. In general practice though I would probably encrypt the login/checkout page just so 'joe user' feels more secure (seeing the little secure icon in the lower left corner.) You dont need to touch any php code, just modify the html so the properlinks point to https where needed. On and advanced note, there are ways to protect a users password on a normal http connection. The authentication program I helped developed and use has the abilty to make a hash of the password on the client side then send the hash value to the authentication script. The authenication script never sees the password just verifies the hash. http://sourceforge.net/projects/diggerauth/ (only cvs version is available, you need ot browse cvs to see the code) HTH, Curt -- "I used to think I was indecisive, but now I'm not so sure." -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
