The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

It seems I'm in trouble with my server. Most of my skripts which actually run fine for the last weeks don't work anymore. One of my problems is this here:
I have a User-section where I use sessions. It worked fine,the login-skript looks like this ( I got it from Kevin's tutorial "Managing user..." )

And I put a :
include("login.php"); ?>
on the top of every skript in the user-area. This worked fine, but now I can log in the user-area, but when I click to the next page in the user section I see the form again to enter my username and password. So it seems that the sessions do not work. As I didn't change the skrip, and it worked fine until yesterday, it seems that some settings on the server changed. Is there any way the check up the settings or check if the session work ore whatever?

php_info() prints out a whole lot of info on the php configeration on the server. There will be a section with all the php session settings. Maybe your host turned sessions off for some reason?!?

BTW, are you querying the database every time a page which includes that script is accessed (which is how it appears to me). That's not necessary. If it helps at all, here is a really simple script I wrote. index.php is the index page of the protected directory.

But what does it mean or how should it look like? Should "session auto start" be set on "ON"?

For the log in skript:I can not see the basic difference. In both cases we check if there is a session "userid", if not we return the form and query the database. So it's just querying the db once, not on every page. Please correct me if I'm wrong.

OK - those session settings look to be the standard/default set up. There should not be a problem there. Also, check the configer command and make sure that track_vars is enabled. You need that to be able to access things like cookie values directly as you do when you refer to $uid in your code.

Hehe - this is the point when someone expert at using php sessions and cookies is supposed to jump in. I just tried to get the ball rolling.

Well to check if sessions are even working try printing the $PHPSESSID after you call session_start(); if you get a value then you know sessions are working. Next thing to do is to attempt to run your script manually, then when you think it has run successfully take that string that was printed out($PHPSESSID), and go into the /tmp folder, look for the file with your session id in the name, open it and you should see some serialized data, in it should be your $userID make sure it has a value. Another good way to debug session data is to put this on every page for debugging

As $PHPSESSID I get a value, so sessions are working.
For the second way I found the file in the /tmp directory, but I can not open ore copy it, and it is not possible to change the permission of this directory.

I would suggest using mysql to store session data, its really easy to setup, all you have to do is create a table in your database and then include about 5 functions that will change the way PHP natively handles sessions from files to a db. Here are the functions you will need to include on every page you want to use sessions. This way it will be much easier to debug you can just look in the sessions table of your db to see what vars are getting set and which aren't

Hey, this looks good. But is it just a makeshift ore do you generally prefer this way. I mean, the one I use worked really fine (until some days ago) and it doesn't need any database querys.
Hey, by the way, what's your hourly rate, I'm sure I would get poor If I had to pay you

Email me at freddy@bereminded.com on the hourly rate thing. No that code is not a makeshift anything, I use everyday for something. It is one of the cool features of PHP, how you can customize how php handles sessions.

yes it is extra queries, but its probably faster than having to open a file and read/write from it. Again, I use this code on a daily basis, and I know it works great.

Please don't PM me with questions.
Use the forums, that is what they are here for.

What I usually do is register $SESSION as session var when I validate the user, then I assign the userid to $SESSION["userid"], in fact I assign all session vars in tothe array $SESSION, that is pretty hard to recreate from a get string, then you can check for

PHP Code:

if ($SESSION["usid"] == "") {
header("Location: index.php");
}

Please don't PM me with questions.
Use the forums, that is what they are here for.

BTW, are you querying the database every time a page which includes that script is accessed (which is how it appears to me). That's not necessary.

I believe that it IS necessary to query the database every time a page is accessed. Querying is done to check if the username and password are valid. If you don't do this then it will be very easy to fool the script by using something like this:

"script.php?$username=anything&$password=nothing".

If you don't query the database, then you will only be able to check if the variables $username and $password are set. With the example above, they ARE set.

Does anyone agree with me? If you don't query the database with every page request, then there will be a security problem.

How are you going to trick the server, with my example it would be very difficult to pass $SESSION["usid"] in a get string, don't you agree, however using a database to hold session data, does mean that the db gest queried with every request, but not to revalidate usernames and passwords but to grab session data.

Please don't PM me with questions.
Use the forums, that is what they are here for.