I am creating an upload feature that stores a user uploaded file on the server with the user's session-id as its name. Now, I want to keep this file on the server only till that session is active.
So, my question is, how can I determine from the session-id, whether a session is active or expired so that in the later case I can safely delete the user uploaded file.
This I want to do as a cleanup at particular intervals maybe by using a cron job, though I have never used it before.
You can't just rely on session.gc_maxlifetime because after this time the session is marked as garbage and the garbage collector starts only with a probability of 1% by default ( session.gc_probability).
The better approach IMHO is to handle yourserlf the expired data.
You can for instance start the time and save it into a session variable:
<?php $_SESSION['last_seen'] = time();//Update this value on each user interaction. ?>
Later..via cron you can do something like this:
<?php
//Get the session id from file name and store it into the $sid variable;
session_id($sid);//try to resume the old session
session_start();
if (isset($_SESSION['last_seen']) && $_SESSION['last_seen'] > $timeout){//Session is expired
//delete file
session_destroy();
}else if (!isset($_SESSION['last_seen')){ //already garbaged
//delete file
session_destroy();
}
?>
Not tested...just an idea
I'm trying to do the exact same thing. One solution would be to define a custom garbage collector function with session_set_save_handler(). In this custom function you would delete the uploaded files associated with the session and then delete the session from disk. The only problem I see it's that you will have to define the rest of the session handlers as well:
bool session_set_save_handler ( callback $open,
callback $close,
callback $read,
callback $write,
callback $destroy,
callback $gc )
This is easy if you don't rely on PHP to handle sessions. Is there a way to call the default handler functions of PHP from a custom handler function?
Intervals can be made like this - someone opens your web -> php script is running -> it checks if files is time-outed -> delete time-oted files
And no CRON needed :-)
It is nearly impossible to determinate due to lack of information if user closed or not the browser window ( if he don't closes it but turn sleep mode on and come back in 2 days - session is still active AFAIK ) -
only idea to slove this problem in best manner this is to use own session engine with AJAX checking.
Related
I want to implement a PHP custom session ID, while avoiding calling session_start() more than necessary.
Basically, one simple algorithm is
session_start();
if ( ! isset( $_SESSION['MyStuff'] )) {
session_write_close();
session_id( generate_my_id() );
session_start();
}
$_SESSION['MyStuff'] = some stuff...;
In case the session expired or didn't exist in the first place, the first session_start() will create its own ID and send a cookie to the browser. Then the session is ended, and another one is created, with another cookie sending (plus the overhead of creating and closing a session file).
Another solution would be to test if a PHPSESSID cookie exists, and its value having the format according to the - home cooked - generate_my_id() function - then test again if the $_SESSION value. But if the session expired (no $_SESSION['MyStuff']), again, a non-necessary session_start() will have been called.
So the question is, based on my observations, actually two questions
is there a way to specify how PHP should create the session ID (doesn't seem to be possible), before calling session_start()?
is there a way to check if session_start() will have to create a new session, or will just use the one available server side? (that would eliminate its first call)
Any good alternative is welcome.
Edit
Clarification about what is a custom id.
The session ID is the string key used by PHP to retrieve a session on the server, each user having a different key. That key is usually stored in a cookie, then the browser sends that cookie with its requests to the server / PHP to "connect" to the session.
PHP sets the session ID key automatically, based on MD5(user-and-time-related-data) or SHA1(same-related-data), based on settings. Thus, the session ID is either a MD5 or a SHA1 key - hopefully unique.
A custom ID is a key created manually by the programmer (me), bypassing the md5/sha1 creation.
Yes, from 5.3 onwards you can specify the hash algorithm with session.hash_function when a session id gets generated; using your own hash algorithm is not recommended, especially since the ones that come with hash are extensively tested for spread, speed, collisions, etc.
Since cookies are typically used to perpetuate sessions, you can use that information to determine whether session_start() will create a new session or not.
The following illustrates a way to minimize the number of session_start() statements you need; it's deduced from existing code (which is OO):
do {
// discover session by cookie
if (isset($_COOKIE[session_name()])) {
session_start();
// validate session contents
if (!isset($_SESSION['MyStuff'])) {
// destroy session and regenerate id
session_destroy();
session_regenerate_id(true); // skip this if you generate your own
} else {
// validation passed, no need to populate
break;
}
}
// populate new session
// you can use session_id($your_id) here
session_start();
$_SESSION['MyStuff'] = 'foobar';
} while (false);
The strange do { } while loop is just a glorified goto so that you can skip the second session_start() if the current session is valid.
Late answer but check the changelog for PHP v5.5.1
It refers a new interface called SessionIdInterface which only method is create_sid, although it's still undocumented.
interface SessionIdInterface {
public function create_sid ();
}
Due to server settings I am having to use $_COOKIE instead of $_SESSION to manage session vars for a project.
On my search form I set an initial cookie but am unclear whether this is helpful or needed?
setcookie('NOSG', 'oHai', time()+7200, '/', 'some.org');
Each time the search results page loads I iterate over the cookies and back date the ones I need to clear and then set the new values like so:
if ($board) {
foreach ($_COOKIE as $k => $v) {
if (preg_match('/boa_/', $k)) {
setcookie($k, '', time()-3600, '/', 'some.org');
}
}
foreach ($people as $p) {
setcookie('boa_'.$p->ID, $p->whatever, time()+7200, '/', 'some.org');
}
}
Mostly this is used for making sticky selections in multi-line <SELECT> inputs.
Is this approach sound? I have rarely used $_COOKIE for anything.
// EDIT 1:12 PM GMT-06:00
All of the comments and answers are focused on fixing sessions. I assume this is because there is some reason the method suggested is NOT sound? The question asked is about using $_COOKIE to remember form settings. Would anyone care to respond as to why the method I am using is or is not appropriate to the problem?
The error
Permission denied. session.save_path is set to /var/lib/php/session PHP Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/var/lib/php/session) in Unknown on line 0
Is due to an error on the part of your host/system administrator. They should set the permissions on /var/lib/php/session to 777 so it is writable by all users. If they are using something that executes your PHP script as your user, the data is still safe because your user will own the session data file so no one else can view or modify it.
Alternatively, you can change the session save path on the fly to a directory under your control.
If you were to have a common file that initiated your session, add this before session_start():
session_save_path('/home/yoursite/sessions');
// or
session_save_path($_SERVER['DOCUMENT_ROOT'] . '../sessions');
// or, an alternate method
ini_set('session.save_path', '/home/yoursite/sessions');
session_start();
Then just created that folder and set the permissions appropriately so it is readable/writable by your user only.
Technically all a session is, is a text file (OK, you can hold the data in a database as well) containing variables that's identified by a value held in a cookie (or the address bar).
It wouldn't be impossible to recreate the functionality within PHP using things like setcookie(), serialize() and file_put_contents() writing to a folder outside the web tree ... though you might also need a Cron job to schedule garbage collection (to be fair, PHPs native session GC doesn't seem to be spectacular).
You'd just need to create a custom session handling object and set the "session" id for it in a cookie exactly the same as if you were using normal session handling - except instead of using $_SESSION you'd use you Session::get() and Session::set() methods.
If you keep the API clean then, at a future date if you manage to get session handling enabled on the server, you'd only need to tweak your session handling object and it wouldn't affect the rest of your program code - it's probably a good idea to abstract away then session handling anyway.
None of the respondents addressed my question: Is using $_COOKIE to store session data a sound method?
Experience has taught me what they would not. Not all browsers handle cookies in the same way. For instance Internet Explorer has limits per domain on the number of cookies: http://support.microsoft.com/kb/941495
So the answer is- $_SESSION is superior to cookies as it is handled by PHP in the same manner for all browsers.
I've used session vars multiple times in the past, with no problems, but now it's got me...
The $_SESSION var I am setting is becoming unset every time the PHP script is fired, although it is setting ok for one variable at a time.
if (!isset($_SESSION['badList'])) {
print 'not set - again?';
$_SESSION['badList'][0] = $lineNum;
}
else
{
$_SESSION['badList'][count($_SESSION)] = $lineNum;
}
Here 'not set - again?' fires every time I perform the suitable action, i.e. PHP is not able to find the initial session var. The session cache seems to clear completely when a script is run, which sort of ruins the point of sessions.
What can I do? Many thanks.
Ensure you've called session_start(), /etc/php.ini (or system equivalent) has a session.save_path set (ususally /var/lib/php/session/) and that directory is writable by your web server (on Linux it should be drwxrwx---) and that your disk is not full. If your sessions are being written to a remote store (database, memcached etc) make sure you can connect to that with the credentials your app uses (if applicable).
edit: also ensure you are calling session_write_close() at the end of your request - if you don't then the session data may not be written
I have a situation where I've started a session with:
session_id( $consistent_session_name_for_user );
session_start();
$_SESSION['key'] = $value;
but then later I decide I don't actually want to "commit" (write) this session. PHP doesn't seem to have any kind of session_abort_write() function. I don't want to destroy the session variables from prior script runs, so I can't use session_destroy()
I tried session_id(""), but that call fails. I could "redirect" the session so it writes to another session, like session_id("trash"), but that would cause a lot of PHP (Apache) connections to try to write to the same session "file", which I want to avoid.
I'm highly simplifying the problem here, we're actually storing sessions in Memcached and this is a complex codebase. So I don't want to be sending unnecessary "trash" sessions to the Memcached server all the time.
From PHP.net,
session_regenerate_id
will replace the current session id with a new one, and keep the
current session information.
session_unset will free all registered variables
session_unregister ( string $name ) will unregister a specific variable
I haven't actually determined if this method prevents writing the session to the session store, but here's the solution I finally used:
session_id( 'trash' ); // or call session_regenerate_id() as someone else suggested
$_SESSION = array(); // clear the session variables for 'trash'.
I'm hoping this has the effect that nothing will get written, but I'm guessing it still will write a blank file, because PHP can't know that sess_trash isn't already there.
If you want to completely avoid writing the session, you'll have to use a custom session handler in PHP and set a global flag to prevent writing the session.
You could probably use something with session_set_save_handler to put dummy functions in for session handling.
<?php
function fakeIt() {
return true;
}
session_set_save_handler("fakeIt", "fakeIt", "fakeIt", "fakeIt", "fakeIt", "fakeIt");
There is session_write_close(). It dumps out the session array to storage and then "closes" it - $_SESSION will still be available and read/writeable, but any changes will no longer be saved, unless you do a session_start() again later on within the script.
I am trying to implement a login system with a 'remember me' feature . This is my my login page: http://pastebin.com/q6iK0Mgy . In this I am trying to extend the session cookie(PHPSESSIONID) expiration using session_set_cookie_params() . But its not working.
Relevant portion from the code: In this the inner if() loop is being executed , but session_set_cookie_params('3600') is having no effect. I am calling session_name() , as it is supposed to be a requirement for session_set_cookie_params() (according to one of the comments on php manual)
if ( isset($_POST["submit"]) )
{
session_name() ;
echo "calling before checked " ;
if ( $_POST["remember"] == "on")
{
// extend expiration date of cookie
session_set_cookie_params('3600');
echo "<br/>calling after sessions_set_cookie_params" ;
}
}
require_once("includes/session.php"); //session start ?>
I hope I was able to explain what I want to do. Basically what I a trying to do is extend the session_cookie's expiration. is my way of doing completely wrong? is there another way to achieve the same ?
thanks
Never too old for an answer right?
So, PHP is dumb. As in, it doesn't do what you think would make sense.
session_set_cookie_param will not do anything until the exact moment that you call session_start. So if you set cookie params after calling session start, too late. If you set the cookie params but then don't call session_start, nothing happens.
session_start is also a funny beast. It only reads cookie data the first time it is called -well that is unless.... you force it to write, or there is no cookie to begin with. So if there is no cookie, it writes the cookie data and the client saves your session. yay! But when the cookie exists already, how to we force it to write, and therefore update our new expiry date??
So, we have this odd effect of ignoring all of your session_set_cookie_param calls if a cookie already exists on the client. Even better, if you explicitly call setcookie(session_name(),blah blah blah), php will STILL not emit the cookie.
So, let's force php to emit a cookie.
option 1
This works by calling session_id with the only value that won't clobber your existing session. Documentation at http://php.net/session_id states that
Note: When using session cookies, specifying an id for session_id() will always send a new cookie when session_start() is called, regardless if the current session id is identical to the one being set.
session_id($_COOKIE[session_name()]);
So anyways it's 6 in the morning and I haven't slept yet and you probably figured this out months if not years ago, but what the hell, maybe i'll save someone else the 2 or 3 hours of my life i'll never get back. ha ha.
From the documentation:
You need to call
session_set_cookie_params() for every
request and before session_start() is
called.
Also check http://www.php.net/manual/en/session.configuration.php#ini.session.cookie-lifetime