Different sites served from the same domain share the session cookie name

Rerolled #35 against 10.1.x

Sorry, I forgot a closing ';'.

Sorry, I forgot a closing ';'.

Rerolled #41 against 10.3.x

@RandalV any chance you can review the MR I just posted and RTBC it - it would be great to fix this problem rather than maintain the patch on this issue.

@alexpott

* MR applies cleanly to 10.3.x
* Done some tests and the results are as expected:
* Same hash salt -> same session cookie name
* Different hash salt -> different session cookie name
* Can stay logged in across all subsites of a multisite on the same hostname with different hash salt
* Giving all subsites the same hash salt has the expected behavior of being logged out when visiting a different subsite

Seems ready to me! Thanks for the MR.

I read the IS, comments, MR and the CR. I didn't find any unanswered questions and I have nothing to add to the MR or CR.
Leaving at RTBC

nod_ → closed merge request !8839

Committed 827acb1 and pushed to 11.x. Thanks!

I'm not sure but seems this is reason of error using php server

https://git.drupalcode.org/project/drupal/-/blob/11.x/.ht.router.php?ref...

Before this fix i had simple way to install Drupal:
1. clone Drupal
2. composer install
3. php -S localhost:8888 .ht.router.php

And i had install form on :8888 right after.

Now i have:

Install form with error:

RuntimeException: Missing $settings['hash_salt'] in settings.php. in Drupal\Core\Site\Settings::getHashSalt() (line 172 of core/lib/Drupal/Core/Site/Settings.php).


Drupal\Core\Site\Settings::getHashSalt() (Line: 119)
Drupal\Core\Session\SessionConfiguration->getUnprefixedName(Object) (Line: 90)
Drupal\Core\Session\SessionConfiguration->getName(Object) (Line: 51)
Drupal\Core\Session\SessionConfiguration->hasSession(Object) (Line: 40)
Drupal\Core\PageCache\RequestPolicy\NoSessionOpen->check(Object) (Line: 37)
Drupal\Core\PageCache\ChainRequestPolicy->check(Object) (Line: 787)
system_form_alter(Array, Object, 'install_select_language_form') (Line: 552)
Drupal\Core\Extension\ModuleHandler->alter('form', Array, Object, 'install_select_language_form') (Line: 826)
Drupal\Core\Form\FormBuilder->prepareForm('install_select_language_form', Array, Object) (Line: 280)
Drupal\Core\Form\FormBuilder->buildForm('Drupal\Core\Installer\Form\SelectLanguageForm', Object) (Line: 972)
install_get_form('Drupal\Core\Installer\Form\SelectLanguageForm', Array) (Line: 1387)
install_select_language(Array) (Line: 697)
install_run_task(Array, Array) (Line: 574)
install_run_tasks(Array, NULL) (Line: 122)
install_drupal(Object) (Line: 48)

Please check.

Created follow issue.
https://www.drupal.org/project/drupal/issues/3470040 🐛 Impossible to install Drupal with php server Active

Re-opening.

Going to set this to closed again - we can fix this in 🐛 Impossible to install Drupal with php server Active - it's an extremely obscure bug caused by no longer needed security fixes.

Oh actually this prevents all interactive installs! Not just php webserver installs. Reverting.

This is happening because code in system_form_alter() is accessing a request policy and therefore the hash salt prior to Drupal even being installed. The work around is to remove the code because as the issues summary of #2421503: SA-CORE-2014-002 forward port only checks internal cache → states

Wait for #2502785: Remove support for $form_state->setCached() for GET requests → : Remove support for $form_state->setCached() for GET requests. If/when that issue is done, this problem goes away since there'd be no $form_state persistence during any cacheable request.

So we can remove system_form_alter.

Pushed an MR that fixes the install issue. We have to test manually because the way the session name is created is different for a site under test.

Appears to need a rebase.