Problem with the session_name

[jrivero]

The session name is obtained from configuration, but later it is used to combine it with a hash of the path where grav is installed. This causes that when deploy the code to the server if we move the path a new session name is generated, and lost all the sessions.

$session_name = $inflector->hyphenize($config->get('system.session.name', 'grav_site')) . '-' . substr(md5(GRAV_ROOT), 0, 7);

I think if you need another name, you have the option for change it, but generate magically modifications on explicit configuration is very wrong.

[rhukster]

What is the use case for sessions persisting across machines where the filesystem layout is different? If you had a cluster would your filesystem not be the same, and therefore the md5 of GRAV_ROOT be identical?

[jrivero]

Hi @rhukster,

For example when use a deploy release strategy, with capistrano or similar.

More information: https://capistranorb.com/documentation/getting-started/structure/

What is the case for which it was thought that it was necessary to reinvent the configured session name when changing the directory that can not be resolved by simply changing the configuration?

[rhukster]

The use case is a very simple one. Having multiple sites on one server in multiple sub-directories. This is an extremely common use case for Grav.

What we really need is a way to uniquely identify an installation, and I have an idea, so let me try it out and let you know.

[rhukster]

Ok, I've made a commit in the 1.6 branch of Grav that uses an md5 of the security salt (which is unique per installation). It will change if you delete your user/config/security.yaml file of course, but that's not a common thing to do.

[rhukster]

Updated with this commit: 3c2a851

Now it defaults to PATH (so you don't get logged out during admin update!), but use the new system.session.uniqueness option to pick salt rather than path if you wish.

[jrivero]

mmm.... I like it!