Issues about storing session files in Public_html

[Jks]

In a PHP membership website hosted in shared hosting, the session used to timeout in 30 minute after closing browser. We solve that problem by creating users.ini file and creating folder 'session' in public_html.

In users.ini file session.cookie_lifetime, session.gc_maxlifetime was extended also session.save_path was set to new directory path. The values of session.cookie_lifetime, session.gc_maxlifetime and session.save_path also set in each PHP program. 

We are facing a new problem about securing folder session that's storing PHP sessions. These are some queries that I have in this regard.

1) Is it possible to have session folder above public_html to avoid direct access? If not then what can be done to secure that folder?

2) Is anything needs to be mentioned in .htaccess to secure users.ini file or session folder? (It currently uses following in .htaccess file: Options -Indexes <Files php.ini> order allow,deny deny from all </Files>)

3) Can anyone directly access session files like sess_xyz123 created in session folder? (We can't browse session files by visiting url www.domain.com/session/sess_xyz123)

4) The session folder gets populated with session files for each user visit to website. How to remove empty session files that are no longer needed when user leaves website?

Looking forward to your reply. Thank you.

Edited yesterday at 02:57 PM by Jks

[Strider64]

I can answer number one and the answer is yes:

<?php
require_once __DIR__ . '/../config/starlite_config.php';
require_once "vendor/autoload.php";

and maybe number 4?
 

 public function logoff(): void
    {
        error_log("Starting logout process");

        // Clear database token
        if (isset($_SESSION['user_id'])) {
            $sql = "UPDATE {$this->table} SET token = NULL WHERE id = :id";
            $stmt = $this->pdo->prepare($sql);
            $stmt->execute(['id' => $_SESSION['user_id']]);
        }

        // Clear login cookie
        $isLocal = in_array($_SERVER['REMOTE_ADDR'], ['127.0.0.1', '::1']);
        $cookieDomain = $isLocal ? '' : 'www.phototechguru.com';

        setcookie('login_token', '', [
            'expires' => time() - 3600,
            'path' => '/',
            'domain' => $cookieDomain,
            'secure' => !$isLocal,
            'httponly' => true,
            'samesite' => 'Lax'
        ]);

        // Clear session
        $_SESSION = [];
        if (isset($_COOKIE[session_name()])) {
            setcookie(session_name(), '', time() - 3600, '/');
        }
        session_destroy();

        error_log("Logout complete");
        header('Location: index.php');
        exit();
    }

 

Edited 18 hours ago by Strider64

[gizmola]

 

18 hours ago, Jks said:

In a PHP membership website hosted in shared hosting, the session used to timeout in 30 minute after closing browser. We solve that problem by creating users.ini file and creating folder 'session' in public_html.

Don't do that.  Under no circumstances should the session storage location be under the web root.  

So first of all, the session does not "timeout" after 30 minutes.  Most likely your shared host has a cron job that is going through the directories where session files are stored and deleting any session files that haven't been updated (the mtime) in over 30 minutes.   Normal session file garbage collection is highly dependent on having a certain amount of requests,  such that the garbage collector actually runs.  

18 hours ago, Jks said:

1) Is it possible to have session folder above public_html to avoid direct access? If not then what can be done to secure that folder?

You should be able to do this.  If it doesn't work, then I wouldn't use the feature.

18 hours ago, Jks said:

4) The session folder gets populated with session files for each user visit to website. How to remove empty session files that are no longer needed when user leaves website?

Hard to say for sure, but you should check the value of gc_probability.  Some OS's like Debian set it to 0, and use os level scripts to remove session files.  As I stated above, it does sound like this might be the case with your host. A site with very low traffic is unlikely to run the session garbage collector in any reliable manner.