Aug 22nd, 2009, 8:35 AM
(Aug 22nd, 2009, 7:49 AM)Ben Wrote: Hey Weaver,
The $g_session_type variable is currently only used internally - for the Form Tools admin section. The API still relies exclusively on PHP sessions. That'll be updated at some point.
- Ben
Here's my update to use database sessions in the API...seems to work.
PHP Code:
/**
* Initiates sessions. The session type (database or PHP) depends on the $g_session_type var
* defined in the users config.php (or default value in library.php);
*/
function ft_api_start_sessions()
{
// old method...
//global $g_api_header_charset;
//session_start();
//header("Cache-control: private");
//header("Content-Type: text/html; charset=$g_api_header_charset");
global $g_session_type;
global $g_session_save_path;
// Copied and pasted from global/session_start.php --brw
if ($g_session_type == "database")
$sess = new SessionManager();
if (!empty($g_session_save_path))
session_save_path($g_session_save_path);
session_start();
header("Cache-control: private");
header("Content-Type: text/html; charset=utf-8");
}
I also added this line to config.php
PHP Code:
// Number of seconds before a session timeouts.
$g_default_session_timeout = 604800;
and these lines to write(...) in sessions.php
PHP Code:
global $g_default_session_timeout;
$life_time = $g_default_session_timeout;
Which gives me a week timeout. Since gc() is overridden in sessions.php, it should give me the full week. (I know it works overnight at least...)
As a final safety measure, it would be great to double check that the session id hasn't changed across forms, and if it does, to throw out some sort of error to the user that they should start over.
BTW, Your code is well written, which makes it pretty easy to trace through and update without breaking things. Nice work!