NYCPHP Meetup

[David Krings]

Adrian Noland wrote:
> I think you need to think about your temp folder idea some more. You
> say that you are going to keep temp uploads and other things there
> that get destroyed after the user logs out. But if you are
> regenerating the user's session ID multiple times you will need to
> keep the temp folder in sync with that.
> 
> I always think about the way online banks do it when I approach this
> problem. They put a META refresh or perhaps a setTimeout() on the page
> and force a page reload. If the request came from the refresh, then
> you know the user isn't paying attention anymore and can dump the
> session.
> 

Note: This is a longer response. I do not write concisely and probably 
will never do. If you are short of time, go on to the next message. 
Also, please keep in mind that I'm a hobbyist who learned PHP from a few 
books, trying things out, and lurking on this list. I never learned 
programming and in fact, I really hate it - with the exception of PHP. 
Stuff is so much easier and more logical in PHP than with Java or C. PHP 
is more like Commodore Basic V2 on the C64, something that is simple 
enough so that I can comprehend it.


Adrian, thank you for your comments. I think I need to explain better 
what I do and I really regret using the term "temp folder" in my 
original post. That folder that I am talking about is not the folder 
that the server creates somewhere for storing the session data. I am 
working on an app that allows me to upload pictures (and later flash 
video) straight from my digital camera into a database supported system. 
The database keeps track of where the picture is stored, the date and 
time it was recorded, the name and description (one for each supported 
language), and ten categories and the location where the picture was 
taken (call it meta tags if you want) per picture and supported 
language. I also store if the picture needs to be rotated on the fly, 
who added it, when it was added, which user level is allowed to view it, 
how often the picture was viewed, when and who viewed it last, and some 
other stuff. Data such as date and time of the shot come from the exif 
header.
I provide a simple browse box for individual uploads. Since I cannot 
control what gets uploaded, I have to accept the upload, then check if 
it is a jpeg or gif. I try to do this by figuring out what the file 
really is rather than to rely simply on the file extension. Once I 
deemed an upload to be a picture file in a supported format, I display 
it in a preview and allow for the entry of the name, description, 
categories, location. For all this checking and previewing I copy the 
file from the location where $_FILE put it into a folder. And THAT 
folder is the one that I create using the session id so that I can 
handle multiple uploads at the same time and not have them cross their 
paths. Once a picture is named and categorized it is written to the 
final storage location, which is a set of folders based on year and 
month. I don't want to rename picture files ever, but it can be that the 
PDRM0692.JPG from 2004 is not the same as the PDRM0692.JPG from 2007. If 
I throw it all into one big folder I will get collision at some point, 
latest after making 10.000 shots with my camera, likely earlier. Also, 
it is much easier to locate pictures in that setting without using the 
system.
While holding the file in the session id named folder and before final 
submission several things can happen. The client can just go away, the 
user can decide not to add the picture (hence the preview from a 
momentary storage location before adding it to the final set of files), 
or other things that leave that session id named folder with content on 
the system. I also allow now uploading of zip archives either directly 
or from an ftp/http accessible location. That way I can stuff several 
dozen (hundred?) files in one go into the system and tag them with some 
bogus name and location (I decided to use ~~~~~~~~), filter the table on 
that, and worry about the correct name and description later. I also 
need this session id named folder for that purpose and things may happen 
(power loss of the server for example, this is the US after all) that 
leave now a considerable amount of gunk behind.
Now I get back to the original question, how can I degunk these folders? 
I need to know which sessions are still likely to be active and which 
ones are not. That all has nothing to do with the temp folder that the 
web server creates somewhere for holding the session data. I have no 
idea where that temp folder is and if I'd now what happens when I just 
dump some files in it (such as the extracted files from the zip 
archive). I really like to know where the files and folders are and thus 
create/copy/move them on my own.

OK, I could use the user ID as well for my folders, but then I'd need to 
guess when the user logged out. Of course, I have a logout function and 
I track last login date and time (maybe even logout, don't remember), 
but I can't expect anyone to use the logout function religiously. People 
just don't do that, they simply kill the browser. With a session id 
based folder for whatever I need to do before final commission I can be 
very sure that after the maximum lifetime of the session and a generous 
grace period that folder with contents is stale and can go. But how to 
know when that session was started?
My first idea was to ask the server which sessions are currently active 
and then ditch all the folders that have session ids as name from 
sessions that are not active. But there seems to be no way for asking 
the server which sessions are currently active. I then decided to simply 
write the session id and a time stamp to a table. And while I am working 
on session tracking, I might as well throw in that extra line to 
generate a new session ID after authentication and before writing it to 
my session tracking table, assuming that this increases security a bit.

I have no idea what banks do and I hope they do a better job than I. I 
do not claim to have designed the most reliable, secure, and optimized 
system. But I can follow its flow and explain what happens where and why 
(and I still can after not working on this project for almost six 
months). And above all, it just works. I am especially amazed how easy 
it was to get the zip stuff working. That is the real power of PHP. You 
want to do gnurf then there is probably a PHP command gnurf() for it. I 
love it! So many people are so much smarter than I am, but I can still 
make use of their ingenuity and unzip uploaded files, read out exif 
headers, and rotate an image on the fly, write a whole bunch of stuff to 
some database, and much more. Uh, and I love PHP's session handling, it 
is so nice to drop stuff into the session and have it available anywhere 
I go rather than to use tons of hidden inputs and post it all over the 
place.

OK, back to work. :)

David