Goran Juric wrote:
It depends on your application, but I don't see disk usage as a problem,
session files are small. And if you are worried about having too many files
in one folder PHP supports creating "leveled directories" for storing
session files. You can look it up on the php.net (although there are some
cons against using this method as stated on their site).
Memcache is not a persistent storage and rebooting your server would delete
all your session data.
Indeed, I appreciate this with memcache with regards to persistent
storage etc, however file based storage has disadvantages in a
multi-server environment with regards to persistence. In one environment
I look after a load balancer ensures that the user is kept on the same
server after initial landing (so file-based session storage is fine) but
if the user were to close their browser they could hit a different
server and thus the file-based session file will not be present.
DB based sessions are a possibility of course, however I like to try and
keep session setup limited to raw PHP config rather than "in code" as I
have had integration issues in the past when trying to bring together
different code into a final package (e.g. embedding an existing
application in apps like Drupal or Joomla or some other CMS via some
kind of bridging component)
I have implanted a system using database as the session storage in my
application. Storing session data in the database made it possible to
implement a system that stores user ID in a separate column of the session
table. This gave me the possibility to delete all session information
related to a particular user if needed.
Interesting.
Use case 1:
User had logged in from various computers or browsers and ticked the
"Remember me" checkbox. When user decides to change his password I can
delete all the session data for this user (except for the one he is using to
change the password). So from all other computers / browsers he will forced
to login again.
OK, seems sensible.
Use case 2:
Storing user "role" and permissions in the session. When the permissions or
the role is changed I can change it across all of his sessions, or just
force him to login again. This way I don't have to hammer the database and
check his permissions on every single request he makes and still be sure
that I can change his permissions.
So you manipulate the serialized session data itself for other sessions?
Or do you hook into the session saving code and write specifically
structured data/fields regarding roles/acl for the user (which is
obviously much easier to alter en-mass!!).
I hope that these examples shed some light on things that are bothering you.
It's very interesting and thanks for taking the time to reply :)
I'm not 100% sure quite how I'll implement things for my "remember me"
function. I'm certainly interested in persisting the session, but I
still do have reservations about this. If I do go down that route, using
the DB sounds like the most sensible option and linking the active
sessions to user ids makes sense to me too. My only real reservation
comes from hooking the actual session saving in the code and the
problems that could arise when bridging the application into other
software like Drupal/Joomla etc. as mentioned above.
Certainly gives me food for though :)
Thanks again.
Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]
