This is not a simple answer, but here is my take: This is only My Opinion. Rule #1: Design your 'working part' of the app to minimize the dependence on stored session. This means to place common actions in the URL. Some people would say that's messy, but I disagree. This is because you can 'Walk in' to any part of the app in ANY stage of the game. Here is an example, the following views are all based on one record, Question #14 in a survey. Here is a complete view of all of the hierarchy: http://www.datafree.com/demo/dc?s=156-157&p=3&m=n&db=survey&d=f&k=3&a=er Now I want to isolate that question with it's answers http://www.datafree.com/demo/dc?s=156-157-158&p=3&m=n&db=survey&d=f&k=197&sn=156-157-158&a=er Now, just view the question itself: http://www.datafree.com/demo/dc?s=156-157-158&p=3&m=d&db=survey&d=f&k=197&sn=156-157-158&a=cr Add a new record? http://www.datafree.com/demo/dc?s=156-157-158&p=3&m=d&db=survey&d=f&sn=156-157-158&a=cr Split the screen: http://www.datafree.com/demo/dc?s=156-157-158&p=3&m=d&db=survey&d=f&k=197&a=er&sw=on In all of these examples, you are 'Walking In'. The system assigns you as a guest. As soon as you continue you will notice a UID (u=xxxxxxxx) being assigned. What happens if you blow it away? Nothing. Now if you have a 'shopping cart' type of app, you will need to track session, because you don't want to be passing every product and other info the User has ordered. I would not store all that crap in cookies either, but one certainly could. So you assign each User a session ID. So now, You want to track a session, You need a unique identifier for each session, Solution: You must somehow pass a session identifier UID Popular choices: 1) Part of the URL ie "sessionid=12234" Drawbacks: A) Could be hijacked if someone guesses what it is Like this: http://www.datafree.com/demo/dc?s=156-157-158&u=202118935938223051&p=3&m=n&db=survey&d=f&k=204&a=er Notice that if you continue with the app, you have hijacked that UID. This is allowed becuse the session is unsecure. B) Session is lost when the User leaves the site, unless they hit the back button. 2) Stored in the users browser as a cookie You can automatically restore the users last session (most people want this) and anything else about them you want to retain. You only need to send the UID once, and the user will hand it back every time. 3) (my choice) Combine the two. If the settings permit guest access, the system instantly adapts and handles the User. But to update, you must create and account and login. When you log in, I toss a cookie. If that cookie ain't there bub, you ain't continuing on (except as a guest). Once logged in, if you disable cookies I will detect it and switch you back to a guest. Finally, a combination of URL UID and cookie UID is the only way (I know of) to allow multiple secure sessions for a single user. A use for this is for developers to develop online web applications, pause and switch to an End User view to test, and quickly switch back. In each case, my system remembers your exact session (last URL, personal settings for that user) and instantly throws you back where you were. Here is a rough flowchart of the process, a bit out of date: http://www.datacrawler.com/images/main_user_mode.gif > You have three main choices for maintaining a "session": > 1) cookies > 2) mangled URLs > 3) hidden fields in forms > If "static HTML" can't do #2 or #3, you are stuck with #1. I don't understand these answers. What is a mangled URL? I don't understand the conclusion about static HTML.
