How in adminer to increase current session on login?

Question

Using adminer-4.7.7 with plugin login-password-less.php I found a way how to enter adminer without credentials entered. But entering adminer I would like to keep the current session as far as possible(including current db and table opened), even after browse closed/opened next day... Has adminer session time parameter/tools? That is for my home laptop ( kununtu18, apache 2, php 7.4), so security breaks are ignored... apache config decisions also possible.

How can I do it ?

MODIFIED : I tried to increase gc_maxlifetime as in Jasar Orion code, but failed

I modified session block in adminer/include/bootstrap.inc.php as:

global $adminer, $connection, $driver, $drivers, $edit_functions, $enum_length, $error, $functions, $grouping, $HTTPS, $inout, $jush, $LANG, $langs, $on_actions, $permanent, $structured_types, $has_token, $token, $translations, $types, $unsigned, $VERSION; // allows including Adminer inside a function

if (!$_SERVER["REQUEST_URI"]) { // IIS 5 compatibility
   $_SERVER["REQUEST_URI"] = $_SERVER["ORIG_PATH_INFO"];
}
if (!strpos($_SERVER["REQUEST_URI"], '?') && $_SERVER["QUERY_STRING"] != "") { // IIS 7 compatibility
   $_SERVER["REQUEST_URI"] .= "?$_SERVER[QUERY_STRING]";
}
if ($_SERVER["HTTP_X_FORWARDED_PREFIX"]) {
   $_SERVER["REQUEST_URI"] = $_SERVER["HTTP_X_FORWARDED_PREFIX"] . $_SERVER["REQUEST_URI"];
}
$HTTPS = ($_SERVER["HTTPS"] && strcasecmp($_SERVER["HTTPS"], "off")) || ini_bool("session.cookie_secure"); // session.cookie_secure could be set on HTTP if we are behind a reverse proxy

@ini_set("session.use_trans_sid", false); // protect links in export, @ - may be disabled
if (!defined("SID")) {
   session_cache_limiter(""); // to allow restarting session
   session_name("adminer_sid"); // use specific session name to get own namespace
// $params = array(0, preg_replace('~\?.*~', '', $_SERVER["REQUEST_URI"]), "", $HTTPS);
   if (version_compare(PHP_VERSION, '5.2.0') >= 0) {
      $params[] = true; // HttpOnly
   }
    $lifetime = time() + 97 * 24 * 60 * 60;
    $params = array($lifetime, preg_replace('~\?.*~', '', $_SERVER["REQUEST_URI"]), "", $HTTPS);

    ini_set('session.gc_maxlifetime', 99600);
   call_user_func_array('session_set_cookie_params', $params); // ini_set() may be disabled

    session_set_cookie_params(99600);

    session_start();
}

It is invalid way? Which way is valid?

Thanks!

Answer 1

If you open file adminer/adminer/include/bootstrap.inc.php:57 you could see the following code:

call_user_func_array('session_set_cookie_params', $params); // ini_set() may be disabled

According to documentation this methods sets session lifetime. By default it set to 0, which means that session will be destroyed when browser is closed. I suppose, you could set another value you want:

$lifetime = time() + 7 * 24 * 60 * 60;    
$params = array($lifetime, preg_replace('~\?.*~', '', $_SERVER["REQUEST_URI"]), "", $HTTPS);

Answer 2

This could be a problem of permission,

can you check in your phpinfo() the value of “session.save_path”, if you are working on localhost this is normally C:\xampp\tmp.

If you are working on ubuntu the session folder should be /var/lib/php/session, if the folder session doesn't exist you should navigate to /var/lib/php/ and create the folder with:

mkdir session

then you need to extend the permission to user www-data, with:

sudo chown -R www-data:www-data /var/lib/php/session

Good luck!

Answer 3

Session timeout is a notion that has to be implemented in code if you want strict guarantees; that's the only way you can be absolutely certain that no session ever will survive after X minutes of inactivity.

If relaxing this requirement a little is acceptable and you are fine with placing a lower bound instead of a strict limit to the duration, you can do so easily and without writing custom logic.

Convenience in relaxed environments: how and why

If your sessions are implemented with cookies (which they probably are), and if the clients are not malicious, you can set an upper bound on the session duration by tweaking certain parameters. If you are using PHP's default session handling with cookies, setting session.gc_maxlifetime along with session_set_cookie_params should work for you like this:

// server should keep session data for AT LEAST 1 hour
ini_set('session.gc_maxlifetime', 3600);

// each client should remember their session id for EXACTLY 1 hour
session_set_cookie_params(3600);

session_start(); // ready to go!

This works by configuring the server to keep session data around for at least one hour of inactivity and instructing your clients that they should "forget" their session id after the same time span. Both of these steps are required to achieve the expected result.

• If you don't tell the clients to forget their session id after an hour (or if the clients are malicious and choose to ignore your instructions) they will keep using the same session id and its effective duration will be non-deterministic. That is because sessions whose lifetime has expired on the server side are not garbage-collected immediately but only whenever the session GC kicks in.

  GC is a potentially expensive process, so typically the probability is rather small or even zero (a website getting huge numbers of hits will probably forgo probabilistic GC entirely and schedule it to happen in the background every X minutes). In both cases (assuming non-cooperating clients) the lower bound for effective session lifetimes will be session.gc_maxlifetime, but the upper bound will be unpredictable.

• If you don't set session.gc_maxlifetime to the same time span then the server might discard idle session data earlier than that; in this case, a client that still remembers their session id will present it but the server will find no data associated with that session, effectively behaving as if the session had just started.

Certainty in critical environments

You can make things completely controllable by using custom logic to also place an upper bound on session inactivity; together with the lower bound from above this results in a strict setting.

Do this by saving the upper bound together with the rest of the session data:

session_start(); // ready to go!

$now = time();
if (isset($_SESSION['discard_after']) && $now > $_SESSION['discard_after']) {
    // this session has worn out its welcome; kill it and start a brand new one
    session_unset();
    session_destroy();
    session_start();
}

// either new or old, it should live at most for another hour
$_SESSION['discard_after'] = $now + 3600;

Session id persistence

So far we have not been concerned at all with the exact values of each session id, only with the requirement that the data should exist as long as we need them to. Be aware that in the (unlikely) case that session ids matter to you, care must be taken to regenerate them with session_regenerate_id when required.