Help!

I'd like to implement the use of sessions and cookies for security reasons within a site I'm building. Additionally, I'd like to log session and user information back to my preexisting customer database.

My problem is: I don't fully understand how to store any of the form, parameter, and customer preference information in a manner that I can recall them (whole or in part) when necessary. Do I have to do a
<?php session_register( "somevar" ); ?> for every field in the form, parameter,and click through? And then, how do I save this information so that I can recall it collectively (one or more of the fields within a form) from another page or multiple pages??? I'm told the combination of session variables SID or PHPSESSID and cookie variables are the way to go, but I'm not sure how to properly meld the two together.

Lastly, I'd like to log the session information back to my customer database.

Thank you.
http://www.healthyproductsplus.com/cust/login.php

    First of all, for security purposes you should not use session_register() at all. If you wish to set $SESSION variables, do it through the $SESSION array and ignore the bazillion outdated books and tutorials you see all over the place.

    If you want to log session information, I would suggest not using native sessions at all. Using native sessions AND database will be basically asking PHP to do the same job twice. For performance purposes I think you would be better off managing your own sessions. Generating the unique ID, doing the URL insertion, and setting the cookie can all be done from your code. The biggest job is setting up the database and it appears you are gonna do that anyway.

    You can build your own from scratch, which might be the most efficient if done properly, or borrow from an existing library such as PHP_LIB (which is what many used before PHP had sessions, and much of PHP's session methodology is based on)
    http://homepage.mac.com/ghorwood/php_lib_login/

      By the way, $SESSIONs do NOT offer security, they offer an easy means to maintain state and a simple place to store variables, but they do nothing to prevent session hijacking. Choosing a $SESSION based system is done for convenience and time considerations, not security.

      Whether you use $_SESSIONs or manage your own, you need to build the security in through your code. This is an often misunderstood concept of sessions.

        First of all, for security purposes you should not use session_register() at all. If you wish to set $SESSION variables, do it through the $SESSION array

        How is session_register() insecure?

          Originally posted by driverdave
          How is session_register() insecure?

          It depends on globals being registered, and users are able to set their own session variables.

          I have only seen one site that gave a comprehensive explanation of the various methods to bypass security on sites that use session_register() and session_is_registered(), it was almost shocking. That page was subsequently removed, and for good reason in my opinion.

          Basically, the methods do not matter. If you look up session_register() at PHP.net you will see a warning even there. PHP quit enabling globals by default for a good reason. They did not do it just to mess everybody up.

          http://www.php.net/manual/en/function.session-register.php

          Caution
          If you are using $_SESSION (or $HTTP_SESSION_VARS), do not use session_register(), session_is_registered() and session_unregister().

            I understand.

            For some reason, the following never occured to me.

            This is all OK?

            //  Use in place of session_register()
            $_SESSION["whatever"] = 26;
            
            //  Use in place of session_unregister()
            unset($_SESSION["whatever"]);

              Originally posted by driverdave
              I understand.

              For some reason, the following never occured to me.

              This is all OK?

              //  Use in place of session_register()
              $_SESSION["whatever"] = 26;
              
              //  Use in place of session_unregister()
              unset($_SESSION["whatever"]);

              [/B]

              That should be fine 🙂 Older versions of PHP need to use $HTTP_SESSION_VARS['whatever']

                Frankly, even though Alaska guys seems to understand, I'm a little bit confused as to what exactly dwalker is trying to accomplish here.

                My take on it is that he simply wants to keep track of where a user goes when she logs in. That and record what they submit in forms (aren't you doing that anyway? You mentioned a database for customers. Can't you just grab the session id and ip address and insert them into the customers records?)

                As for the security of sessions, yes, they are not made for security's sake. They are made to keep state for a state-less protocol...ip. However, nothing transmitted from client to server and vice-versa is ever secure without using encryption. Therefore, SSL and good programming can make a site adequately secure when passing sensitive information accross the wire. This means as has been previously emphasized, registering session variables globally isn't neccessarily the smartest way to go about securing things. So set your session variables with $SESSION['name'] = value; and so forth. Also, test your variables against $SESSION['name'] in the $_SESSION array. Just an example, say I have a login page that checks a username and password against a databse query. If the query validates, I set a session variable ($loggedin = true). If I set it globally, it is possible to reset the value using a variable from another source (like a plain 'ole cookie perhaps, or a POST or GET) with the same name. I'm not sure which variable names will take precedence, however, I just know it's generally a bad idea.

                If you are not really protecting sensitive data and just want to use sessions for tracking a user as she goes through your site, sessions offers a great way to go. For example, I would just include a script in your header that inserts the session id into a database. When your users log in, make sure you insert a record into an associated table with their ip and current and session id. Later, you can go back and link the session ids to a user login record.

                  For example, I would just include a script in your header that inserts the session id into a database. When your users log in, make sure you insert a record into an associated table with their ip and current and session id. Later, you can go back and link the session ids to a user login record.

                  Whoops, that was a bit confusing on my reread. Guess I shoudl proofread before posting ;-)

                  I didn't completly convey my suggestion:

                  The first thing you do is insert a login record with userid, ip and session_id (at least) upon a successful login, of course ;-)

                  Then this little include file I suggested inserts the session_id and $_SERVER['SCRIPT_NAME'] into a yet another association table and thus, keeps track of where that user went when they were logged in. You might want to store the ip address with these records just to verify against the server logs (the server logs will have aproximately the same time, files, and ip stored).

                  Hope that clears me up. AND good luck!

                    Originally posted by bretticus
                    Frankly, even though Alaska guys seems to understand

                    Maybe, maybe not. Dwalker's 'log session and user information' is a bit vague, I envisioned a much more complex log than you did. If your assesment of the question is correct, it would lessen the relevance of my suggestion significantly.

                      Please forgive me for what might seem a very unorthodox request, but would you be in a position to 'test' the authentication methods on my site?? I want to be sure that I've set things up properly. I've been behind the keyboard all day trying to piece all this new information together.

                      OH! Yes, you were correct about my tossing form data into my database and wanting to keep track of where and when my users are -- I'll use the information to make the site better as time goes on.

                      Here's the scoop on my unfinished site:
                      the two most important things for me are: 1) protecting the customer account information; 2) making sure that when my customer clicks any of the ADD TO CART buttons, I've already verified their contact information.

                      Please let me know what you think.

                      Thanking you in advance.

                        Originally posted by MrAlaska
                        Maybe, maybe not. Dwalker's 'log session and user information' is a bit vague, I envisioned a much more complex log than you did. If your assesment of the question is correct, it would lessen the relevance of my suggestion significantly.

                        You are correct in that my database currently consists of 50 different tables and I will have a product list of over 1500 items. I plan on doing quite a bit of logging (with my ISP's permission).

                        Thank you for you help.

                          Originally posted by dwalker
                          Here's the scoop on my unfinished site:
                          the two most important things for me are: 1) protecting the customer account information; 2) making sure that when my customer clicks any of the ADD TO CART buttons, I've already verified their contact information.

                          1) As Bretticus mentioned, SSL is needed if security is a high priority. Also, to secure sessions, you need to collect as many client side variables as possible to validate against on every secure page request. The most common are user IP and browser/OS information.

                          2) That part is easy, just give them a login screen instead of the 'add to cart' screen if they are not logged in. You will probably want to retain the item chosen, also. You will need to do that by saving the data and passing it either through a session variable or GET/POST or COOKIE.

                            Originally posted by dwalker
                            You are correct in that my database currently consists of 50 different tables and I will have a product list of over 1500 items. I plan on doing quite a bit of logging (with my ISP's permission).

                            Thank you for you help.

                            The relative points if my initial response here would depend on how much logging through this script you want to do in the database, and how much data you want to keep on what customer is looking at what item and how many times and how long they stayed on the site and that kind of stuff. If you want to tie it to specific customers, then managing your own sessions would be advised in my opinion. If you are keeping that detailed of a log, you might also want to turn OFF your server logs, which are keeping the same information but not paying attention to user_id's.

                            [EDIT] Or, an alternative as Bretticus mentioned, go back later and compare user ip's with server logs would be another method of tracking[/EDIT]

                              Originally posted by MrAlaska
                              1) As Bretticus mentioned, SSL is needed if security is a high priority. Also, to secure sessions, you need to collect as many client side variables as possible to validate against on every secure page request. The most common are user IP and browser/OS information.

                              2) That part is easy, just give them a login screen instead of the 'add to cart' screen if they are not logged in. You will probably want to retain the item chosen, also. You will need to do that by saving the data and passing it either through a session variable or GET/POST or COOKIE.

                              Thank you for your assistance.

                              I'm glad you mentioned "saving the data and passing it either through a session variable". How is passing through a session variable effectively done? I want to make the site as user friendly as I can: should I attempt to use a combination of session variable AND cookie? What is your recommendation? Can you provide sample pseudo code for me to study and learn from???

                                Originally posted by dwalker


                                Thank you for your assistance.

                                I'm glad you mentioned "saving the data and passing it either through a session variable". How is passing through a session variable effectively done? I want to make the site as user friendly as I can: should I attempt to use a combination of session variable AND cookie? What is your recommendation? Can you provide sample pseudo code for me to study and learn from???

                                I am not a proponent of depending on client side variables for ANY aspect of site functionality, including cookies. Using cookies and sessions at the same time would be redundant and serve no purpose.

                                Passing it through a $_SESSION variable is simple, Bretticus showed you the code for that or the manual gives some examples:
                                http://www.php.net/manual/en/ref.session.php

                                Making the site user friendly is up to you, a user friendly site the client will be clueless as to the methods you use. All they care about is if it works!

                                  Write a Reply...