Installing via the UI no longer logs in user 1 every time [#2108623]

Updated: Comment #19

Problem/Motivation

Installing via the UI no longer logs in user 1 reliably.

Eg myself (@larowlan using simplytest.me and chrome) and @ParisLiakos (5.5) reported it didn't work
@andypost (5.3.14) reported it did in chrome but not in firefox.
@tim.plunkett tried chrome on 5.3.14 and 5.4.4, and neither worked.

This means we can't do the front page tour.
And that the initial experience is that of an anonymous user.

Diagnosis: user is logged in in install_configure_form_submit(). Later, in install_finished(), drupal_flush_all_caches() re-initializes user session:

  $cookies = \Drupal::request()->cookies;
  if (($cookies->has(session_name()) && ($session_name = $cookies->get(session_name()))) || ($is_https && Settings::get('mixed_mode_sessions', FALSE) && ($cookies->has(substr(session_name(), 1))) && ($session_name = $cookies->get(substr(session_name(), 1))))) {
    // If a session cookie exists, initialize the session. Otherwise the
    // session is only started on demand in drupal_session_commit(), making
    // anonymous users not use a session cookie unless something is stored in
    // $_SESSION. This allows HTTP proxies to cache anonymous pageviews.
    drupal_session_start();
    if ($user->isAuthenticated() || !empty($_SESSION)) {
      drupal_page_is_cacheable(FALSE);
    }
  }
  else {
    // Set a session identifier for this request. This is necessary because
    // we lazily start sessions at the end of this request, and some
    // processes (like drupal_get_token()) needs to know the future
    // session ID in advance.
    $GLOBALS['lazy_session'] = TRUE;
    $user = new AnonymousUserSession();
...

Proposed resolution

Move user log in into install_finished()

Remaining tasks

Tests - is this testable? I see only manual testing option
Review

User interface changes

None

API changes

None

Comment	File	Size	Author
#24	interdiff-24.txt	461 bytes	valthebald
#24	2108623-24.patch	1.2 KB	valthebald
#19	2108623.patch	1.11 KB	valthebald

Comments

Comment #0.0

larowlan

🇦🇺🏝.au GMT+10

commented 9 October 2013 at 21:45

Issue summary:

View changes

Updated issue summary.

Comment #1

andypost

he/him

Russian

commented 15 October 2013 at 13:42

Now I get the issue in all browsers

Comment #2

tim.plunkett

he/him

English

Philadelphia

commented 17 October 2013 at 17:01

It works on minimal profile, but not standard.

Comment #2.0

tim.plunkett

he/him

English

Philadelphia

commented 17 October 2013 at 17:01

Issue summary:

View changes

Updated issue summary.

Comment #3

larowlan

🇦🇺🏝.au GMT+10

commented 10 November 2013 at 23:14

This is definitely the cron run, and something to do with cookies, the cookie sent by the browser is removed by Drupal, a new session is created - so the old one is invalid.
Removing the call to cron in install finished fixes it, note that this doesn't occur in minimal either.
Lee

Comment #4

elvis2 commented 12 November 2013 at 10:31

@larowlan, can you provide a patch to test?

Comment #5

sun

German

Karlsruhe

commented 13 December 2013 at 22:41

Issue summary:	View changes
Related issues:		+#2155701: Installer starts with fatal error/exception "table 'semaphore' not found" if settings.php contains $databases already

Comment #6

andypost

he/him

Russian

commented 13 December 2013 at 23:28

some days ago (when install in other then English language work) no login was needed after install

Comment #7

sun

German

Karlsruhe

commented 14 December 2013 at 18:28

note that this doesn't occur in minimal either.

I'm not able to confirm this. I re-installed a couple of times with Minimal profile this week and was never logged in after installation.

Scanning the changelog of install.core.inc, there are two issues that touched the final uid 1 user account saving and login procedure:

#2002650: [meta, no patch] improve maintainability by removing unused local variables
#1987896: [Change record update] Convert user_page() to a new style controller

However, I'm not able to see how these could have broken the final login/authentication.

Comment #8

sun

German

Karlsruhe

commented 12 February 2014 at 02:41

The interactive installer is now covered by proper automated tests, due to #2171683: Remove all Simpletest overrides and rely on native multi-site functionality instead

The automated tests are passing. Therefore, this issue can have two potential causes:

A parallel HTTP request hits the Drupal site within the installer before the site is fully set up. → e.g., the built-in PoormansCron facility in core (a cron run triggered through a JS callback)
Something else quite possibly related to either cron or sessions.

Comment #9

sun

German

Karlsruhe

commented 27 February 2014 at 03:33

#2205295: Objectify session handler reliably reproduces this bug in automated tests (out of a sudden), so it is likely going to be fixed as part of that issue.

Comment #10

kartagis

Turkish

Istanbul

commented 20 March 2014 at 14:33

I git pull'd yesterday and installed, the error seems to have gone away.

Comment #11

tim.plunkett

he/him

English

Philadelphia

commented 20 March 2014 at 17:30

I'm still logged out after installing.

Comment #12

berdir

German

Switzerland

commented 20 March 2014 at 17:58

Noticed today that I was logged in when doing a non-english installation (german), but not when installing with english.

Comment #13

kartagis

Turkish

Istanbul

commented 21 March 2014 at 07:29

Yeah, I can confirm #12. In my case, it was Turkish.

Comment #14

znerol commented 26 March 2014 at 20:55

It seems that this is related to the batch process running as the last step (when translation is enabled) and lacking (when installing in english).

Comment #15

znerol commented 26 March 2014 at 21:21

Funny detail: I end up as logged in user when installing with JavaScript disabled. That explains why it was not detected by the tests. I suspect that the '/system/timezone' Ajax callback is causing the trouble.

Comment #16

tim.plunkett

he/him

English

Philadelphia

commented 26 March 2014 at 22:51

I also am logged in when I install with JS off. Nice find @znerol!

Comment #17

sun

German

Karlsruhe

commented 26 March 2014 at 22:58

Yeah, that confirms my suspicion in #8.

Either some Ajax callback or PoormansCron, or some other funky/fragile JS callback (#post_render_cache, active-links, .....)

Comment #18

valthebald

Sofia

commented 28 March 2014 at 13:06

Assigned:

Unassigned

» valthebald

I have narrowed it to commenting the call to

        var path = 'system/timezone/' + abbreviation + '/' + offsetNow + '/' + isDaylightSavingTime;

in timezone.js

Now looking what could be the issue

Comment #19

valthebald

Sofia

commented 29 March 2014 at 11:48

Issue summary:	View changes
Status:	Active	» Needs review
Issue tags:		+Needs manual testing

Status	File	Size
new	2108623.patch	1.11 KB

Comment #20

valthebald

Sofia

commented 29 March 2014 at 11:48

Issue summary:

View changes

Comment #21

andypost

he/him

Russian

commented 29 March 2014 at 12:50

Status:	Needs review	» Reviewed & tested by the community
Issue tags:	-Needs manual testing

Awesome!
Tested in FF and chrome, also simplytest.me

Comment #22

sun

German

Karlsruhe

commented 29 March 2014 at 14:56

Awesome that you fixed it!

However, what is the actual fix (or problem)...? How does moving those two lines change the situation?

Is it possible to cover that in a code comment, to prevent those lines to get mistakenly moved to somewhere else by someone else in the future? :)

Comment #23

valthebald

Sofia

commented 29 March 2014 at 16:04

@sun: I was not able to track it down to the end, yet I'm sure that it happened due to different handling of user session by install.php (all the way until the final step) and index.php (request to TimeZone controller). It went like this:

install.php: All the way of install.php user session exists (uid = 0, but there is batch info)
install.php:final step of install.php loads. User session still present
index.php:timezone AJAX call destroys user session
install.php:install.php is submitted
install.php:user 1 is updated, session is regenerated, but not saved
install.php:since session doesn't exist (it was destroyed by #3), it is reset by cache clear

Also, chances are that the issue is related to session subsystem still using global $user. Hopefully this will go away from core

Comment #24

valthebald

Sofia

commented 29 March 2014 at 19:26

Status	File	Size
new	2108623-24.patch	1.2 KB
new	interdiff-24.txt	461 bytes

Added comment

Comment #25

catch

he/him

English

commented 30 March 2014 at 11:51

Status:

Reviewed & tested by the community

» Fixed

Nice find. Committed/pushed to 8.x, thanks!

Comment #26

30 March 2014 at 11:52

Commit 766586b on 8.x by catch:

Issue #2108623 by valthebald: Installing via the UI no longer logs in...

Comment #27

13 April 2014 at 12:01

Status:

Fixed

» Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

Installing via the UI no longer logs in user 1 every time

Problem/Motivation

Proposed resolution

Remaining tasks

User interface changes

API changes

Related Issues

Comments

Related issues

Referenced by