This prevent side-effects between test cases via session that might
or might not pre-exist on disk.

As discussed in zendframework/zend-expressive-session-ext#44 (comment). Once that other PR is merged, I'll rebase this one to remove that time() usage that won't be necessary anymore.

Do test improvements also require a CHANGELOG entry ?

Provide a narrative description of what you are trying to accomplish:

• Are you fixing a bug?

  • Detail how the bug is invoked currently.
  • Detail the original, incorrect behavior.
  • Detail the new, expected behavior.
  • Base your feature on the master branch, and submit against that branch.
  • Add a regression test that demonstrates the bug, and proves the fix.
  • Add a CHANGELOG.md entry for the fix.

• Are you creating a new feature?

  • Why is the new feature needed? What purpose does it serve?
  • How will users use the new feature?
  • Base your feature on the develop branch, and submit against that branch.
  • Add only one feature per pull request; split multiple features over multiple pull requests
  • Add tests for the new feature.
  • Add documentation for the new feature.
  • Add a CHANGELOG.md entry for the new feature.

• Is this related to quality assurance?

• Is this related to documentation?

Originally posted by @PowerKiKi at zendframework/zend-expressive-session-ext#46

By default php ext-session locks the session file until the end of the script execution or until session_write_close is explicitely called, thus blocking any other xhr request. This can affect a SPA's execution time. Should we start the session with the read_and_close option "on" and reopen the session file when and if we need to persist session data (if it changed from the initial reading)?

Originally posted by @pine3ree at zendframework/zend-expressive-session-ext#26

Bug Report

Summary

New issue connected to issue #3

Current behavior

The sessions_start() in function startSession() can cause an ErrorException under certain circumstances.

How to reproduce

Create an environment, where the options set in startSession are defined in a per-host configuration

Expected behavior

No ErrorException.

I started this in issue #3 but never found the cause for the descripted behaviour.

But I stumbled across this comment in the comments section on php.net for the command "ini_set":

"I have experienced on some systems that ini_set() will fail and return a false, when trying to set a setting that was set inside php.ini inside a per-host setting."

Okay, he is talking about ini_set() and not session_start(), but that's exactly the cause in my case. in my local development environment I don't have host-specific ini-settings. So that exception was never thrown there. But on my production server it's the case. There is a global php.ini but for the host (apache environment) are certain ini-settings defined. "use_cookies" is one of them and when I removed that from the host ini-settings the same error was thrown but this time for "use_only_cookies" (the next parameter in order in your session_start() call).

So I suspekt that this is the cause for the exceptions.

Feature Request

Summary

This is more a comparison of behavior of mezzio-session-ext implementation vs the php ext-session.

1. calling session_start() via php-ext-session always sets a session-cookie in the first session-aware script's response even if no data is actually stored in the session. mezzio-session-ext only sets a response session-cookie if the session-data is changed or the session is regenerated. see (*)

2. php-ext-session sets the session-cookie in the response only if the session-id is changed either when the session is fresh (new) or its id is regenerated. mezzio-session-ext always sets the response session cookie if the session-data has been altered even if the session-id is unchanged. see (*)

3. php-ext-session always sends cache-limiters headers after a session_start() call. mezzio-session-ext only sends cache-limiters headers when the session-data ( or the session is regenerated) has been changed (*)

4. after calling session_start()(or session_regenerate_id()) the actual session id is available right away and may be used programmatically to identify the client browser session in the first fresh-session-generating script execution. With mezzio-session-ext in a fresh session or a regenerated session context the actual/final session-id is only available inside PhpSessionPersistence::persistSession() . see (**)

5. feature/maybe BC: php-ext-session does not set a new session-cookie (with same id) if we only change the session-cookie-lifetime. It would be useful to make mezzio-session-ext always send a new cooki when the session-lifetime is changed ($session->persistSessionFor()). This could be achieved allowing null to be returned in SessionCookiePersistenceInterface::getSessionLifetime(). A null value could be used to indicate that the cookie-lifetime has not been changed, any unsigned int to programmatically set the cookie-lifetime, 0 for restoring to a session-cookie.

6. BC renaming of SessionCookiePersistenceInterface methods
   we now have:

• SessionIdentifierAwareInterface::getID()
• SessionCookiePersistenceInterface::persistSessionFor(int $duration)
• SessionCookiePersistenceInterface::getSessionLifetime()

In my opinion we should have for consistency:

• SessionCookiePersistenceInterface::persistFor(int $duration)
• SessionCookiePersistenceInterface::getLifetime()

so that we can make calls call $session->getLifetime() and $session->persistFor(86400). The word 'Session' in the method seems redundant to me, same as $session->getSessionID() would seem.

(*) behaviours 1 and 2 (and 3) could be achieved in PhpSessionPersistence::persistSession() by comparing the initial session-id (from the request) with the final value and by calling PhpSessionPersistence::regenerateSession() even if only $id === '' or by triggering a $session = $session->regenerate() when $id === '' and then checking $session->isRegenerated(). (edited/added) We would also need to be able to distinguish when data changed or id has been regenerated, right now hasChanged() checks for both cases.

(**) behavior 3 could be achieved partially using a new SessionIsNewAwareInterface featuring an isNew() method. The new session id would be generated and set in the session instace along with a $isNew constructor param. But I haven not find a way to get the final id from the session instance after a regenerate() call in the inner handler. A SessionIsNewAwareInterface is the solution I have been adopted in my code, to both achieve fresh data-less session and session-id availability inside my handlers code. About that, php session books states that:

• Session support in PHP consists of a way to preserve certain data across subsequent accesses.
• A visitor accessing your web site is assigned a unique id, the so-called session id. (...)
• The session support allows you to store data between requests...

So php-ext-session always assigns a unique id and allows you to store data. I interpret this as 'data-less' an only 'client-identifying' session behavior

kind regards

related issue: #5

• I was not able to find an open or closed issue matching what I'm seeing.
• This is not a question. (Questions should be asked on slack (Signup for Slack here) or our forums.)

Treating connections to server themselves on their own merit. Session is not just a variable bag/container to hold some values. It is a way of reasoning the idea of a link between client and server. There does not need to be explicit data persisted between requests to develop workflows focusing around tracking a particular visitor.

That said, it is very easy to work around by setting dummy variable at the beginning of the pipeline. However, if you already know how PHP session works this is unexpected behavior. Therefore, if above notion is rejected, there should be a warning in documentation stating that this library works differently from how people are used to work with PHP. Can spend days debugging, only to find out the framework changed traditional behavior.

Specific usecase example. I have a "go to meeting" style workflow. A financial advisor logs in, initiates a meeting. Needs his client to see in real time how data in form is filled in. Sends one time token link to client who does not have account on intranet system to participate in the meeting. Hash in link is checked to be used one time on a single connection attempt using session_id() . But if follow up background requests during the meeting create new sessions, I cannot rely on session_id() + token combo as one of checks to verify the connection is still coming from the same person.

Expected results

• Follow understood PHP workflow
• Not needing to set up dummy variables in session to force same session key when client needs to be tracked without login credentials.
• Only time session should be reset, is a deliberate developer action, such as, upgrade or downgrade authentication access role, or want to discard currently tracked guest connection.

Actual results

• Sessions reset unexpectedly.

Originally posted by @alextech at zendframework/zend-expressive-session-ext#23

There is a use case when session already started before, and already set some value, eg: on csrf session data on a login form. When authenticate, it call the session regenerate, which session id changed, but left the old session not persisted (unset not applied as session id changed), so old session with the value remain in the disk.

To avoid it, I think we can apply session_destroy() before session_write_close() whenever session is active.

Originally posted by @samsonasik at zendframework/zend-expressive-session-ext#47

Feature Request

Summary

As decided during the Technical-Steering-Committee Meeting on August 3rd, 2020, Laminas wants to implement vimeo/psalm in all packages.

Implementing psalm is quite easy.

Required

• Create a psalm.xml in the project root
• Copy and paste the contents from this psalm.xml.dist
• Run $ composer require --dev vimeo/psalm
• Run $ vendor/bin/psalm --set-baseline=psalm-baseline.xml
• Add a composer script static-analysis with the command psalm --shepherd --stats
• Add a new line to script: in .travis.yml: - if [[ $TEST_COVERAGE == 'true' ]]; then composer static-analysis ; fi
• Remove phpstan from the project (phpstan.neon.dist, .travis.yml entry, composer.json require-dev and scripts)

Optional

• Fix as many psalm errors as possible.

Feature Request

7.4 needs dropping here. Once outstanding PRs are merged, I'll drop it, update the lock and bump all the dev deps

Feature Request

Summary

To be prepared for the december release of PHP 8.0, this repository has some additional TODOs to be tested against the new major version.

In order to make this repository compatible, one has to follow these steps:

• Modify composer.json to provide support for PHP 8.0 by adding the constraint ~8.0.0
• Modify composer.json to drop support for PHP less than 7.3
• Modify composer.json to implement phpunit 9.3 which supports PHP 7.3+
• Modify .travis.yml to ignore platform requirements when installing composer dependencies (simply add --ignore-platform-reqs to COMPOSER_ARGS env variable)
• Modify .travis.yml to add PHP 8.0 to the matrix (NOTE: Do not allow failures as PHP 8.0 has a feature freeze since 2020-08-04!)
• Modify source code in case there are incompatibilities with PHP 8.0

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Repository problems

These problems occurred while renovating this repository. View logs.

• WARN: Use matchDepNames instead of matchPackageNames

Awaiting Schedule

These updates are awaiting their schedule. Click on a checkbox to get an update now.

• Lock file maintenance

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update dependency phpunit/phpunit to v11

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

BC Break Report

Summary

After upgrading my project from PHP 7.2 to 7.4 all requests done in my application return this warning. The warning is triggered in the file PhpSessionPersistence.php, on the first line of the method startSession, when session_id($id) is called. I tried to upgrade the package to the version 1.9.0, but the error persists. There is a similar bug reported regarding the session_name function and apparently it was introduced in PHP 7.2, but I never had any issues before the upgrade to PHP 7.4. I've done a lot of research about this issue but I couldn't find a proper solution, that's why I decided to open this issue. I found very odd that no one else reported it, so I decided to give it a shot.

I found two ways to bypass this problem:

private function startSession(string $id, array $options = []) : void
{
    @session_id($id); // Ignore the warning
    session_start([
        'use_cookies'      => false,
        'use_only_cookies' => true,
        'cache_limiter'    => '',
    ] + $options);
}

== OR ==

private function startSession(string $id, array $options = []) : void
{
    if (!session_id()) { // Check if session is already set beforehand
        session_id($id);
    }
    session_start([
        'use_cookies'      => false,
        'use_only_cookies' => true,
        'cache_limiter'    => '',
    ] + $options);
}

I ran the tests using the versions 1.7.4 and 1.9.0 with PHP 7.4 and they were successful.

Override session configuration by setting session key in config directory

Summary

Modify the constructor of the PhpSessionPersistence.php class to override the session configuration by setting variables in an array under the session key. Why. This would be consistent with being able to set other session parameters....

For example:

// file: config/autoload/session.global.php
return [
    'session' => [
		'session.name' => 'own_session_name',
		'session.cookie_secure' => true, 
		'session.cookie_httponly' = true,
		...
        'persistence' => [
            'ext' => [
                'non_locking' => true, // true|false, true => marks read_and_close as true
            ],
        ],
    ],
];

See mezzio/mezzio-session#17

Opening an issue here too because dflydev/fig-cookies is a direct dependency here too

Packagist currently seems not auto updated. @weierophinney could you check? thank you.

Hello!

I upgraded zendframework/zend-expressive-session-ext in my project from version 1.3.0 to 1.4.0.

I don't know why, but with this version I got an error exception when startSession is called:

private function startSession(string $id, array $options = []) : void
{
    session_id($id);
    session_start(array_merge([
        'use_cookies'      => false,
        'use_only_cookies' => true,
        'cache_limiter'    => '',
    ], $options));
}

ErrorException: session_start(): Setting option 'use_cookies' failed.

So I removed the "use_cookies => false" line but the same error message with "use_only_cookies" was thrown. Only after I removed that line too it worked. I changed nothing else in my code, only updated the composer package.

Here are my php.ini settings:

igbinary session support => yes
session.auto_start => Off => Off
session.cache_expire => 180 => 180
session.cache_limiter => nocache => nocache
session.cookie_domain => no value => no value
session.cookie_lifetime => 0 => 0
session.cookie_path => / => /
session.cookie_secure => 0 => 0
session.gc_divisor => 1000 => 1000
session.gc_probability => 1 => 1
session.lazy_write => On => On
session.name => PHPSESSID => PHPSESSID
session.referer_check => no value => no value
session.serialize_handler => php => php
session.sid_bits_per_character => 5 => 5
session.sid_length => 26 => 26
session.upload_progress.cleanup => On => On
session.upload_progress.enabled => On => On
session.upload_progress.freq => 1% => 1%
session.upload_progress.min_freq => 1 => 1
session.upload_progress.name => PHP_SESSION_UPLOAD_PROGRESS => PHP_SESSION_UPLOAD_PROGRESS
session.upload_progress.prefix => upload_progress_ => upload_progress_
session.use_strict_mode => 0 => 0
session.use_trans_sid => 0 => 0
session.trans_sid_hosts => no value => no value
session.trans_sid_tags => [a lot of tags...]

And these settings are set in the website-configuration.

session.gc_maxlifetime = 3600
session.save_handler = redis
session.save_path = "tcp://172.30.0.65:6379?weight=1"
session.cookie_httponly = 1
session.use_cookies = 1
session.use_only_cookies = 1

Originally posted by @Musiksammler at zendframework/zend-expressive-session-ext#32