2

I am looking for insights into how to destroy a specific session in PHP. Through a partner website a user logs into the main website using a token and obtains a full session.

It is also possible for the partner website to call a destroy function if the user logouts from the partner website. We should then also log out our own user.

What is the best approach to this? The Zend_Session destroy method does not accept a parameter, similarly the PHP function session_destroy does neither.

I am considering two options:

  1. Removing the session information directly from file/memcache but would prefer a "cleaner" approach than this.

  2. Checking at every page request if this is a "token" user ; and if then check if their token was expired by maintaining a list. This adds overhead to a busy website, but might be my only option.

Or is there a third / better approach I am not seeing?

Tramov
  • 1,166
  • 1
  • 11
  • 17
  • possible duplicate of [Unset a specefic session using session id](http://stackoverflow.com/questions/6703842/unset-a-specefic-session-using-session-id) – symcbean Jul 18 '11 at 09:03

3 Answers3

4

There's no need to roll-your-own session handling.

session_id() can take a parameter, the session id you want to work with.

So, when you pass the user off to the partner site, pass along their session_id (or some token, or whatever).

Then allow the partner site to hit a script like this:

kill-user-session.php

<?php
/**
 * Destroy any active session identified by $_POST['sid']
 */
session_id($_POST['sid']);
session_start(); //this line may not even be necessary
session_destroy(); //destroys that session.

So when the user logs out on the partner site, the partner site POSTs the session_id (that you gave them) to your kill-user-session script, and the user's session is destroyed on your server.

Of course, you probably want to limit access to kill-user-session.php via some method or another.

timdev
  • 61,857
  • 6
  • 82
  • 92
1

If you wish to be able to 'kick' the sessions of a user(s), the only way you can do it is if you use MySQL (or someother db, sqlite even) for your session storage.

Then you can simply remove entries from the db to kill a session.

This also allows you do do things such as, 'take control' of a specific user's session and other stuff :)

See this for a very basic run through: http://www.devshed.com/c/a/MySQL/Custom-Session-Management-Using-PHP-and-MySQL/ (not the best example but good enough full example to start you).

EDIT

Also, if logging out through the partner site, another method I have used in the past (which was with O2 and other such sites) they were given a 'callback' (REST API call in most cases) which they would also need to call when the user logs out of their site.

Brian
  • 8,418
  • 2
  • 25
  • 32
  • Interesting idea -- a quick Google however gave the following insights, which apply as this is a busy webserver with many concurrent users (hence the use of memcache for sessions) : " It has been put by some that SQLite is not intended for a write intensive environment as it uses a single file for the database. Every time a session is updated the database file is locked and so that multiple sessions must be updated one at a time rather than together. Another problem could be corruption. Should a single SQLite based session be corrupted, all sessions will be lost." – Tramov Jul 18 '11 at 08:20
  • 1
    personally i wouldn't use SQLite either ... just illustrating PHP can use multiple methods for it. I have used MySQL for session management with PHP for a very long time now, from 'simple' cms systems, to call center apps. – Brian Jul 18 '11 at 08:24
  • thanks for the link, its a great howto into rolling your own session management routines. – Tramov Jul 18 '11 at 08:39
  • Yip, if you combine this with some API call that they should call when someone logs out of their site this will be a flexible solution in more than one way :) – Brian Jul 18 '11 at 08:41
  • Brian - your answer is fine, you're completely incorrect that you need mySQL or any custom session back-end to do this. See my answer, which provides a simple solution that should work with any session storage back-end, including the default file-based one. – timdev Jul 18 '11 at 12:39
  • doing it your way would indeed also work, but also is a potential security risk. Using some API etc will ensure the request came from an authenticated source - or I would hope he will do as such :) – Brian Jul 18 '11 at 12:45
  • "the only way you can do it" - nonsense. Almost universally, if your PHP code has access to a single session it has access to all sessions - delete the file, unmap the memory page, delete the record - and as per my comment above, you can use the session handler to do it for you in about 3 lines of code. – symcbean Jul 18 '11 at 13:14
  • @Brian - absolutely, you don't want the mechanism to log out arbitrary users to be runnable by anyone. Obviously some kind of authentication and transport security would be in order. – timdev Jul 19 '11 at 09:26
-2

The database solution means that the session database needs to be shared between mainwebsite and the partner site, which frequently isn't the case etc. Maybe something along these trivial lines would suffice?

<img src="mainwebsite/logout.php">

mainwebsite/logout.php:

<?php session_destroy(); ?>
Einar Lielmanis
  • 347
  • 1
  • 4
  • He was asking how to destroy a specific session, not the current user's one. – Brian Jul 18 '11 at 08:30
  • As I see it, the essence of his problem is logging out the currently logged in user of the main website, while being on the partner website. – Einar Lielmanis Jul 18 '11 at 08:31
  • Sorry yip, but your answer still doesn't provide a seamless user experiance. I will retract my down-vote tho - edit your answer so I can do so :) – Brian Jul 18 '11 at 08:39