Closed (fixed)
Project:
Drupal core
Version:
8.0.x-dev
Component:
user system
Priority:
Major
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
15 Sep 2014 at 10:37 UTC
Updated:
3 Oct 2014 at 09:40 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
znerol commentedComment #3
znerol commentedFixing test-failures:
SessionManager::start()inSessionTestSubscriber.TestClass.EntityCrudHookTestis aDrupalUnitTest, there is no need to use the$_SESSIONhere at all. Just substitute it with$GLOBALSFrom the fixes above, #2 may be objectionable. In this case a
drupal_set_message()call was issued before the session was active. In my opinion this points to an issue code withdrupal_set_message()which simply assumes that someone else will care about setting up the session.The reason why this does not work anymore is the change in
SessionManager::startReal()which only will backup session data if the session actually was (lazy-)started before. This is more explicit and IMHO the correct behavior.Comment #4
moshe weitzman commentedCan you explain the drupal_set_message() change a bit more? Calling this function will still open a session?
I Just found the tiniest possible nit.
typo: gloabl
Comment #5
znerol commentedFirst thing to note is that
drupal_set_message()stores a message in the$_SESSION.In Drupal 7
drupal_session_initialize()was called unconditionally during the bootstrap and all code running afterDRUPAL_BOOTSTRAP_SESSIONcould expect that things just work. It even was possible to populate the$_SESSIONbefore that bootstrap stage becausedrupal_session_start()would just merge preexisting data after starting the session.In HEAD, the session currently is started as soon as something triggers authentication by calling some method of the
current_userservice. Under normal circumstances, this happens in theMaintenanceModeSubscriber. Basically we have the same behavior in HEAD like in D7, except that it is implicit. Granted this is very fragile and there is still a considerable amount of work to do in order to completely separate user authentication from the session code.The patch changes the behavior slightly when starting a session. Instead of merging preexisting data it does the following: If a session was loaded from the disk, only data from the disk will be used. If a session was started lazily before, only preexisting data added to
$_SESSIONbetween the lazy start and the real start is kept.The reason for giving up the unconditional data-merge in the
startReal()-method is that due to the Symfony session bags, the content of$_SESSIONis not flat anymore. It would be rather difficult to always merge the flat (Drupal) session data and the Symfony session bags correctly.The session-merge is what changed in the patch, and the service provider test exposed that.
Comment #6
znerol commentedComment #7
moshe weitzman commentedThat all sounds reasonable to me. Would be great to get another eye on this before RTBC.
Comment #8
cosmicdreams commentedYES! THIS!
This was pretty confusing the first time I saw it. So happy we're making this easier to understand.
sorry to quibble but startReal makes me thinking your creating a new reality.
How about forceStart
otherwise the patch looks good to me.
Comment #9
znerol commentedWhat about
startNow()?Comment #10
cosmicdreams commentedSOLD
Comment #11
alexpottCommitted 195503e and pushed to 8.0.x. Thanks!
I'm not 100% sold on startNow or startReal - but it is a protected method so I don't care too much. It should return a bool - just like parent::start(). Fixed on commit.