Code: Select all
$old_name = session_name();
//validate_user opens the centralized authentication session and verifies user authenticity
//also, validate_user calls session_regenerate_id to prevent session fixation
if(!validate_user()) {
session_write_close();
session_name($old_name); //restore old session name (PHPSESSID)
header('Location: login page');
exit();
}
elseif(!user_has_right('domain_admin')) {
session_write_close();
session_name($old_name);
header('Location: error page');
exit();
}
session_write_close();
session_name($old_name);
//squirrelmail code which utilizes sessionsRight now I am using my authentication code to "wrap" the target application. For example:
If an application takes $_POST['user'] and $_POST['pass'] to validate a user, my auth code inputs values into $_POST to match what is needed, thus bypassing the login page that the target application implements. Is this logic appropriate?
In particular, I had one script that would write all of its session data into the centralized authentication session (this is bad since both the auth session and the script session used many of the same names). I ended up creating an auth_landing.php file that would read the appropriate data and forward the user to the script page thus preventing the script from accessing the auth session. Will I have to do this with all my scripts.
It seems to me that if you do the follow, everything should work as expected with data being stored to its respective session:
Code: Select all
session_name('SESSION_ONE');
session_start();
//manipulate some session data
session_write_close();
session_name('SESSION_TWO');
session_start();
//mamipulate some more session data
session_write_close();