2

For my Joomla! 3.8+ extension I need to be able to find and delete (unlink) PHP session files (named 'sess_' + session id) which will be stored in the session_save_path, e.g. /tmp. I understand that it is PHP who is storing the session files, i.e. not Joomla! (Joomla! session handler set to 'PHP') My question: Will a PHP session file that is created through the use of the Joomla! website ALWAYS be read/write accessible by my extension's PHP code which is part of the same Joomla! install?

Addition: I realised later, that I omitted the word 'always' in my question, which I have now added.

Addition: More in-depth explanation about what I am trying to achieve. As I said I have a Joomla! site, where users can log into. The issue applies ONLY when Joomla! is configured with Session Handler set to 'PHP' (instead of 'database'). When Session Handler is 'database', there is no problem.

In basic terms, I want to achieve the following (with Joomla! session handler set to 'PHP'):

1> A user opens browser A and logs into the website and Joomla! records the related session ID plus user ID in a database.

2> The same user opens a different browser B (maybe at a different IP) and wants to log into the same website.

3> Because user has already logged into the website through browser A, he/she is not allowed to log in again and will be presented a clickable link that will destroy all his other sessions, including the one with browser A (we have recorded the session IDs of all the other sessions).

A mere session_destroy() in step 3 is just partly doing the trick, because the destroyed session details reappears after a little while at the Joomla! backend and also in the Joomla! session table. Although this does not interfere with the Joomla! front-end, it is not clean and I want to avoid it, to make it fool proof. By far the best solution is if I could delete the PHP session file (for example in dir /tmp and named 'sess_....'). I have tested this and it worked fine. However... it relies upon always having delete access to the PHP session file (using session_save_path() and unlink($session_file_path)) and this is the basis of the question that I posted. I found out that the delete of the PHP session file is not always possible; it depends on the providor's PHP config. Since it is a commercial app that I am developing, the process must work on all configs, i.e. including those that do not allow delete access to the session file.

I will continue my search for a solution and will post it here when I found it.

RobHU
  • 35
  • 6
  • I don't know Joomla, but what if the server is configured to use either a database or a cache for session data? – Nigel Ren Nov 01 '18 at 15:09
  • Just curious, what problem are you trying to solve that requires you to delete PHP sessions directly? Maybe there is a different solution? – Ryan Vincent Nov 02 '18 at 18:56
  • 1
    @RyanVincent I have edited my post to include the answer to your question – RobHU Nov 04 '18 at 10:51

3 Answers3

1

What you want is often possible but it poses a security risk (just think: one user can read session files before knowing who they belong to, so also those of other users), and therefore security-conscious ISPs will endeavour to prevent this.

So even if you manage to do this, nothing assures you that your code isn't going to break should the ISP tighten its security in the future. This makes for some maintenance uneasiness.

A better solution would be to have a secondary table of invalidated session-ids.

Then you write a user plugin hooking the onUserAuthorization and onUserLogout events. You will need onAfterInitialise too.

This hook will check upon initialisation whether the current session ID has been invalidated; if it is, immediate logout is triggered. Otherwise, its timestamp is updated.

On user logout, the current session id is removed from the table and the session destroyed.

At a fresh login, a warning about other sessions being open is issued: if login succeeds, all other sessions for the same user will be marked as invalidated.

As a maintenance task, all entries with a timestamp older than maximum session lifetime may safely be expunged.

LSerni
  • 55,617
  • 10
  • 65
  • 107
  • @LSemi Thank you for your comprehensive answer. Yes I noticed that many ISPs allow deleting PHP session files, but not all. For this 'not all' part I had to come up with an alternative and I finally did it exactly the way you suggested. The fact that you are bringing this method up too, tells me that I did the right thing. Thanks again and regards. – RobHU Nov 05 '18 at 17:54
  • @RobNL you should now either accept an answer, or (if you think it is really unlikely this will ever be useful to someone else - I'd disagree, but it's your call of course) maybe delete the question. – LSerni Nov 05 '18 at 22:17
0

That depends on the server settings.

  1. Find the user PHP is using: How to check what user php is running as?

  2. Check the permissons of that user on the folder where the sessions are stored: Unix: How to check permissions of a specific directory?

  3. Change the permissions when needed: https://serverfault.com/questions/105535/how-can-i-set-full-premissions-to-a-user-in-a-specified-dir

AgeDeO
  • 3,137
  • 2
  • 25
  • 57
0

Thank you @Nigel and @AgeDeO

By trial and error, I found out that the answer is NO, not always. By executing the code with a few commercial ISPs, I hit one ISP who did not allow me to delete the PHP session file while it was at its default location. The location was /var/lib/php5.

RobHU
  • 35
  • 6