When to use sessions?

[feck]

Hello,I was wondering when the best time to use sessions was. The application in question is a simple validate a user/password against a mysql database, now when would be the time to start using the session?Before or after confirmation of the users existence within the database?Thanks

[reportingsjr]

After, you set some session such as this: $_SESSION['online'] to yes if the database result turned up with one result (one user) and don't set it at all if no results were returned. Then on every page use and if to check is $_SESSION['online'] == "yes". (You could also set it to true if on false if not on. Don't use quotation marks then.) So try that out.

[jlhaslip]

Depends what you want to use the session variable for. If it is to track the user's login-in information across numerous pages, then after log-in is when you will have the information. To track the referring page, then before. These are only two examples of what the sessions could be used for. My point is that it would depend on what information you want to maintain during the session.

[feck]

Thanks people,Yes the application in question would, once logged in', enable further access to the site.Just one other thing what a fantastic forum, why I didnt find it sooner I'll never know, when I use the tutorials so much.Thanks again

[jesh]

This probably doesn't apply to your situation, but it is good to keep in mind that sessions only work when you have a single web server. If you are developing an application that might require a scale up to multiple web servers, you'll have to use some other means of keeping track of state.

[DeathRay2K]

Personally, I like to use a combination of cookies and session cookies, so that the user can be logged in instantly and stay logged in through multiple sessions.

[justsomeguy]

I like to store all of my session info in the session only (i.e. only use the session on every page), but on a login page or something I'll check for a cookie and copy everything in the cookie into the session. That way, I only have to worry about the session, but if the cookie is present then it will overwrite what is in the session.

[Skemcin]

@jesh - I'm not sure your statement is entirely accurate - depending on how exactly you meant it. What is true is that a session cannot be carried over from one server to another if they are not configured to do so - i.e. google cannot read a session from your recent yahoo visit. However, if you are working in a cluster server environment, then your sessions can be carried from one server to another (at least with ColdFusion). However, browser sessions can cause you problems as well. Internet Explorer, for one, is the only browser that I have found to operate each browser instance as a stand alone application session and therefore a session is not able to be adapted from one window to another.Anyway, session variables are very powerful if they are thought through thoroughly. Personally, I never use client-side cookies in my applications so I do everything in the session scope. As soon as you hit any of my sites, I have a set of default session variables that track any number of things that determine your experience on the site. Once logged in, more access driven control is dictated by more session variables that were defined during the login process.So, my short answer is, use sessions before and after a log in.

[jesh]

@Skemcin - I'm working for a website which has multiple web servers for hosting. If a user is on one web server, the next request will most likely continue on the same server so typical session tracking may work. However, depending on load, the next request may fall over to another server. In this situation, typical session tracking will fail because all of the session information will be on the original server. To get around this, yes, we have to cluster the servers and use a third party software solution to keep track of the session data.I just want to add that, like Skemcin said, we use session data before login, during login, and after login - through the entire user experience.