Details

      Description

      The path for (php) session files has been modified in eZ Publish 5.3, files are now stored outside the cache folder.
      Because of this, the default php cleanup scripts/cron do not cleanup the files (default php session files is /var/lib/php5)

      Steps to reproduce:
      1. Login to the site
      2. Verify the session files are created in ezpublish/sessions, and will not be purged automatically.

        Issue Links

          Activity

          Hide
          Joao Inacio (Inactive) added a comment - - edited

          This occurs after the change in https://github.com/ezsystems/ezpublish-community/pull/133

          A possible alternative could be to use the default php handler configuration, this would also make sure files aren't saved in cache path.

          # app/config/config.yml
          framework:
              session:
                  # handler_id set to null will use default session handler from php.ini
                  handler_id: ~
          

          Ref: http://symfony.com/doc/current/cookbook/session/sessions_directory.html

          Show
          Joao Inacio (Inactive) added a comment - - edited This occurs after the change in https://github.com/ezsystems/ezpublish-community/pull/133 A possible alternative could be to use the default php handler configuration, this would also make sure files aren't saved in cache path. # app/config/config.yml framework: session: # handler_id set to null will use default session handler from php.ini handler_id: ~ Ref: http://symfony.com/doc/current/cookbook/session/sessions_directory.html
          Hide
          Jérôme Vieilledent (Inactive) added a comment -

          this prevents the default php cleanup scripts/cron from working properly.

          Which scripts/cron are you referring to?
          If your talking about session garbage collection, settings from php.ini are used to purge sessions, unless you define session options in framework.session.*.

          Sounds a documentation issue to me, at least linking to Symfony documentation.

          Show
          Jérôme Vieilledent (Inactive) added a comment - this prevents the default php cleanup scripts/cron from working properly. Which scripts/cron are you referring to? If your talking about session garbage collection, settings from php.ini are used to purge sessions, unless you define session options in framework.session.* . Sounds a documentation issue to me, at least linking to Symfony documentation.
          Hide
          Jérôme Vieilledent (Inactive) added a comment -

          Besides, forcing framework.session.handler_id to null will change the session storage from NativeSessionStorage to PhpBridgeSessionStorage, which is slightly different and thus might lead to unexpected issues. It's OK to use this setting in your project though (this is use config, it's meant to be modified), but I'm -1 using this by default.
          Furthermore, we'd like to be as close as Symfony default configuration as possible.

          Show
          Jérôme Vieilledent (Inactive) added a comment - Besides, forcing framework.session.handler_id to null will change the session storage from NativeSessionStorage to PhpBridgeSessionStorage , which is slightly different and thus might lead to unexpected issues. It's OK to use this setting in your project though (this is use config, it's meant to be modified), but I'm -1 using this by default. Furthermore, we'd like to be as close as Symfony default configuration as possible.
          Show
          Damien Pobel (Inactive) added a comment - https://doc.ez.no/eZ-Publish/Technical-manual/4.x/Reference/Configuration-files/site.ini/Session/SessionTimeout Same kind of doc to add for the new stack
          Hide
          André Rømcke added a comment - - edited

          Updated documentation as part of EZP-22523 to reflect current behaviour, and in theory there should not be a issue here:
          https://doc.ez.no/display/EZP/Session

          Short: yes cronjob does nothing, but Symfony forces session.gc-probability by default, so it should clear session files on every 100th request by default (assuming session.gc_divisor is at default value: 100). I also mentioned in the doc that you can change setting back to system save_path to get cronjobs to purge old sessions if you want.

          So I'm assuming testing to reproduce this used wrong assumptions.

          Show
          André Rømcke added a comment - - edited Updated documentation as part of EZP-22523 to reflect current behaviour, and in theory there should not be a issue here: https://doc.ez.no/display/EZP/Session Short: yes cronjob does nothing, but Symfony forces session.gc-probability by default, so it should clear session files on every 100th request by default (assuming session.gc_divisor is at default value: 100). I also mentioned in the doc that you can change setting back to system save_path to get cronjobs to purge old sessions if you want. So I'm assuming testing to reproduce this used wrong assumptions.
          Hide
          Pedro Resende (Inactive) added a comment -

          Tested and approved by Q.A.

          Show
          Pedro Resende (Inactive) added a comment - Tested and approved by Q.A.

            People

            • Assignee:
              Unassigned
              Reporter:
              Joao Inacio (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0 minutes
                0m
                Logged:
                Time Spent - 2 hours
                2h