session set safe handler ,error reporting and etc.....

[cherri8]

Hi, Session set safe handing is abit confusing for me to use now even though i can get the codes on the net.I will not be able to store sessions in database without the session set safe handler.if I always change session id when users login than i shouldnt have to use session set safe handler? is this code alone good enough to use to change id? .i got the code from wikipedia : //accept only SIDs generated on my serverif (!isset($_SESSION['SERVER_GENERATED_SID'])) { session_destroy(); // destroy all data in session}session_regenerate_id(); // new sid$_SESSION['SERVER_GENERATED_SID'] = true; Are errors safe in the error log on server? and is this code that i got at php.net good enough to use for error logging? my purpose is to not display errors to people. /* 00.00.00.00 is replace with the site owner ip address.*/// Report all PHP errorserror_reporting(-1);if($_SERVER['REMOTE_ADDR']=="00.00.00.00"){ini_set('display_errors','On');}else{ini_set('display_errors','Off');}

[justsomeguy]

If you're talking about the session save handler, you can use that to store your session data in a database or somewhere else instead of the default file handling for sessions. There are some examples here that use classes to handle the session functions: http://www.php.net/manual/en/function.session-set-save-handler.php

if I always change session id when users login than i shouldnt have to use session set safe handler?

I'm not sure how regenerating the ID relates to using a custom session handler. You don't need to use a custom handler, you would only do that if you want to use a way to save sessions other than the defaults.

Are errors safe in the error log on server?

It depends where the log is, if it's the system log then it's fine, otherwise it's preferable to use an error log that is not publicly accessible.

and is this code that i got at php.net good enough to use for error logging? my purpose is to not display errors to people.

I prefer to always write errors to a log file, regardless of who is accessing it. Error logging is especially important for ajax development where you may not even see the output of the script. error_reporting(E_ALL);ini_set('error_log', dirname(__FILE__) . DIRECTORY_SEPARATOR . 'error.log');ini_set('html_errors', 0);ini_set('log_errors', 1);ini_set('display_errors', 0); That will set PHP to report all errors in a file called error.log in the same directory as the script. Like I said, it's preferable to save the error log in a location that people can't open it from a browser.

[cherri8]

If you're talking about the session save handler, you can use that to store your session data in a database or somewhere else instead of the default file handling for sessions. There are some examples here that use classes to handle the session functions: http://www.php.net/m...ave-handler.php I'm not sure how regenerating the ID relates to using a custom session handler. You don't need to use a custom handler, you would only do that if you want to use a way to save sessions other than the defaults. It depends where the log is, if it's the system log then it's fine, otherwise it's preferable to use an error log that is not publicly accessible. I prefer to always write errors to a log file, regardless of who is accessing it. Error logging is especially important for ajax development where you may not even see the output of the script. error_reporting(E_ALL);ini_set('error_log', dirname(__FILE__) . DIRECTORY_SEPARATOR . 'error.log');ini_set('html_errors', 0);ini_set('log_errors', 1);ini_set('display_errors', 0); That will set PHP to report all errors in a file called error.log in the same directory as the script. Like I said, it's preferable to save the error log in a location that people can't open it from a browser.

Thanks for help :Happy: . I thought that the session set safe handler was also use to prevent people's session ID from being stolen. I'll only use the session regenerate Id and not the session set safe handler. I'll just use the defaults. If I put error in files ,I'll store them in the private directory on server that is above the public directorys.

[justsomeguy]

Checking like that and regenerating the ID wouldn't necessarily protect the session. If someone gets a session ID from someone else and puts it in a cookie, the server will look that up and find all of the correct data in the session. If you want to make sure people don't steal other sessions then you should store unique values like the user's IP address and user agent string and compare those each time to make sure they match for the same session. That's still not perfect, but people would at least need to be on the same IP and have the same user agent string in order to steal it.

[Guest So Called]

Or a hash of the IP address plus user agent string.

[cherri8]

Checking like that and regenerating the ID wouldn't necessarily protect the session. If someone gets a session ID from someone else and puts it in a cookie, the server will look that up and find all of the correct data in the session. If you want to make sure people don't steal other sessions then you should store unique values like the user's IP address and user agent string and compare those each time to make sure they match for the same session. That's still not perfect, but people would at least need to be on the same IP and have the same user agent string in order to steal it.

Thanks.So far i already have $_SESSION['ipcheck'] = true;(when ip is already found in database) and $_SESSION['logincheck'] = true;(when password and username is found in database).I'll use this code below that i found on wiki that has user agent.ill change up some stuff in code.The user agent stuff is new to me s i had to google it.if (strpos($_SERVER['HTTP_REFERER'], 'https://DiD/') !== 0 || isset($_GET['LOGOUT']) || $_SERVER['REMOTE_ADDR'] !== $_SESSION['PREV_REMOTEADDR'] || $_SERVER['HTTP_USER_AGENT'] !== $_SESSION['PREV_USERAGENT']) session_destroy(); session_regenerate_id(); // generate a new session identifier $_SESSION['PREV_USERAGENT'] = $_SERVER['HTTP_USER_AGENT'];$_SESSION['PREV_REMOTEADDR'] = $_SERVER['REMOTE_ADDR']; Edited June 5, 2012 by cherri8

[cherri8]

Or a hash of the IP address plus user agent string.

Thanks i'll check user agent string with ip. I dont know how to decode after hashing stuff so i hope that i dont need to decode user agent string.ill put hash user agent string in database.

[Guest So Called]

You're welcome, but just note: I haven't done this stuff but I've heard about it and just repeating what aI heard. What I understand is that you use a one-way hash and store the result. Upon having the hashed result (perhaps carried in your $_SESSION) you can't work backwards and calculate the terms (IP address and UA string). Rather, you just rehash the IP and UA each time using the same hash and compare that with the stored value. No need to decode, and in fact that's a benefit because a hacker can't calculate backwards either. That's one good reason why hashes are used. Hashes are also often used in forum software to hash username and password, so that if the database is compromised the hacker can't calculate backwards to get the passwords.

[birbal]

I thought that the session set safe handler was also use to prevent people's session ID from being stolen

session_set_save_handler() makes session safer when it stores data in database. in shared host the session data is stored in flat files usualy. and all of user/ other sites hosted on that server use same sources. so it is not safer that if that one is compromised your session data will be compromised. saving in db will make it more secure. but that does not makes secure from stealing session id from any user as justsomeguy already stated. you dont have to use session_regenerate_id() unless you want to regenrate id explicitly. when you star a session it checks that any of session cookie or propogated session id is there are not. if its there it resumes to it else it genrate new one. if you want to check against ip and user agent you have to store it in database. there is callback for reading session data in session_set_save_handler() in that function you have to check the ip an user agent and session id combo. when it matches make the data read. same with write callback. you should check the link jsg posted to get the idea.

$_SERVER['REMOTE_ADDR'] !== $_SESSION['PREV_REMOTEADDR'] ||$_SERVER['HTTP_USER_AGENT'] !== $_SESSION['PREV_USERAGENT'])

when you use to check integrety of session using $_SESSION['PREV_REMOTEADDR'] here it already read the data from the current activated session. you have to do the checking before it read. that is what for session_set_save_handler() for. it let you customize session behaviour

[cherri8]

session_set_save_handler() makes session safer when it stores data in database. in shared host the session data is stored in flat files usualy. and all of user/ other sites hosted on that server use same sources. so it is not safer that if that one is compromised your session data will be compromised. saving in db will make it more secure. but that does not makes secure from stealing session id from any user as justsomeguy already stated. you dont have to use session_regenerate_id() unless you want to regenrate id explicitly. when you star a session it checks that any of session cookie or propogated session id is there are not. if its there it resumes to it else it genrate new one. if you want to check against ip and user agent you have to store it in database. there is callback for reading session data in session_set_save_handler() in that function you have to check the ip an user agent and session id combo. when it matches make the data read. same with write callback. you should check the link jsg posted to get the idea. when you use to check integrety of session using $_SESSION['PREV_REMOTEADDR'] here it already read the data from the current activated session. you have to do the checking before it read. that is what for session_set_save_handler() for. it let you customize session behaviour

Thanks you all. Thanks Birbal :I wanted to make my own codes for session_set_save_handler() when I use it to understand it more instead of using the ones that are already made on the net. I notice that most people only use mysql_real_escape_string in handler which wouldn't be enough to filter stuff. It would be more work for me to think of which filters to use for every session data which is one of the reasons why I wanted to use session_set_save_handler() later because im in a rush to finish site for important reasons lol. I already know that I have to use this to filter session id: if ((preg_match('/[^a-zA-Z0-9-,]/i', $sessid ))!==TRUE). If I don't use the handler I did plan to make a mysql query at the login page to put the session id+user agent in database.After i will get ip from database that was put there during signup than put session id+user agent+ip in session at login page.yah it sounds like allot of work my way and confusing too lol.It seems that with session_set_save_handler() I don't have to do a mysql query every time to put session data in database.

[cherri8]

I will look at the codes on the net to understand session handler better

[justsomeguy]

There's an example here, although it's a bit old and doesn't use best practices (e.g., mysql instead of mysqli, and global variables instead of a class): http://w3schools.inv...?showtopic=9731

I notice that most people only use mysql_real_escape_string in handler which wouldn't be enough to filter stuff.

mysql_real_escape_string isn't for filtering, it is to make sure the data you're trying to put in the database makes it there and doesn't break the SQL query.

[cherri8]

There's an example here, although it's a bit old and doesn't use best practices (e.g., mysql instead of mysqli, and global variables instead of a class): http://w3schools.inv...?showtopic=9731 mysql_real_escape_string isn't for filtering, it is to make sure the data you're trying to put in the database makes it there and doesn't break the SQL query.

thanks it helps.