slim-session: session_set_cookie_params(): Cannot change session cookie parameters when session is active

I can safely say that I feel pretty silly right now.

When I set up my project I used the slimphp/slim-skeleton. Let me show you what its index.php looks like really quick:

<?php
if (PHP_SAPI == 'cli-server') {
    // To help the built-in PHP dev server, check if the request was actually for
    // something which should probably be served as a static file
    $url  = parse_url($_SERVER['REQUEST_URI']);
    $file = __DIR__ . $url['path'];
    if (is_file($file)) {
        return false;
    }
}

require __DIR__ . '/../vendor/autoload.php';

session_start();

// Instantiate the app
$settings = require __DIR__ . '/../src/settings.php';
$app = new \Slim\App($settings);

// Set up dependencies
require __DIR__ . '/../src/dependencies.php';

// Register middleware
require __DIR__ . '/../src/middleware.php';

// Register routes
require __DIR__ . '/../src/routes/index.php';

// Run app
$app->run();

See the issue? It calls session_start() before loading the middleware, including your slim-session package. Thus, since the session has already started, all the initialization and configuration in your package throws the warnings I’ve been seeing.

Sorry for wasting your time xP I will definitely be putting more time into debugging before submitting an issue in the future. Now that I’ve discovered Tracy, that should be easier for me.

And: nope, there’s no ini_set under the hood: https://github.com/php/php-src/blob/php-7.2.7/ext/session/session.c#L1662-L1733

OK, I think you just got it right. PHP needs a call to session_start on each request to be able to work with session data (reading and writing, cleaning, etc), and Slim just provides middlewares for that purpose: tasks to be run before or after the request is processed or ‘answered’, that’s why __invoke first starts the session and then processes the request. PHP keeps session data under two circumstances: the GC didn’t got a cycle yet (which is why initially this package was full of ini_set calls making GC more tolerant but newer PHP comes preconfigured to have a poor probability to run it and also disk space shouldn’t be a problem because session data is saved in serialized form), or if the session cookie is still alive (which is why we need to setcookie a lot on each request to a newer expire time so autorefresh works, otherwise PHP will just clear out the session and start another without advice and no matter if the server got a new request during the lifetime). I rejected the session_write_close call because, if you look at the code, it’s meant to destroy the entire session and forcefully write data to the handler (by calling $handler->write), which is what you don’t want to do on each request (believe me, or call it each time and you’ll see lots of session files). If you’re afraid of the configuration being ignored, just install my package, and change in vendor the Session class by adding a var_dump before each call, you’ll see that all of the functions after the check run, unless, as you said, other package didn’t call session_start before in your middleware stack. Here you have a quick and clean solution available: call add first for this package and later for the other ones that want to mess the session, it’s not that hard to fix that if you think about it. Maybe a good choice here would be to document it in the README stating clearly that this package should go before any other that manages sessions (I thought it was clear before because I didn’t put // Other middleware comment before the call to add. The other thing is, as you might have figured out, that this package allows you to use your custom session handler, it doesn’t lock you to session files as other packages do. You can write your own handler or integrate another one (illuminate/session for example includes its handlers standalone) without having lots of package starting sessions randomly so breaking your app. You want a database, a Redis store, a memory store (PS: it’s PHP nature haha), a do what you want store? Write a handlerfor it and this package will use it as you tell it. If we get rationale, PHP emits those warnings for something: for you to be careful of only calling those functions once in your entire app (i.e. request). If you try to do it twice, it will cry with their stupid warnings. And yes, all of we know sessions are a sensitive piece of shit we should take seriously and carefully, so we can’t just go making salad with user’s data (some people stores its entire profile data in a session). Maybe it sounds I’m trying to impose my package over others, but it’s not like that, first because it says “simple” in the description, and second because there are too few alternatives to make it right (illuminate/session, I’m looking at you again).

Hello! Can you aprove the patch?

Thank´s!