Problem/Motivation
When running a manual test of Drupal 6 upgrade to Drupal 8 using the migrate_upgrade UI, with a D6 site having several hundred user accounts and thus requiring more than one batch to import all the users, when proceeding to the second batch of uses the migration dies with a 404 for the path '/'. The 404 is a red herring - the main point is that importing the admin account data changes the admin account password, which regenerates the user session, which changes the CSRF token used by the batch API.
Proposed resolution
Either
- Fix it in batch API: #2607478: Batches broken by password change, or
- Make sure we don't change the admin password on migration - this would probably be less surprising to the admin user than having it set to the legacy site password, or
- Both.
Remaining tasks
Decide whether we should change the migrate side.
User interface changes
N/A
API changes
Presumably none
Data model changes
Presumably none
| Comment | File | Size | Author |
|---|---|---|---|
| #20 | interdiff.txt | 1.28 KB | mikeryan |
| #20 | migration_of_uid_1-2606466-20.patch | 6.05 KB | mikeryan |
| #7 | migration_of_uid_1-2606466-7-FAIL.patch | 3.68 KB | mikeryan |
Comments
Comment #2
mikeryanActually, at least some of the problem here is not having views enabled in D8, so when the migration sets the front page to /node (which is a view) then the front page is a failure. Doing something intelligent when the front page configuration we're importing leads to a non-existent path is one issue - another is the UI breaking if uid 1 is updated, not quite sure yet to what extent they're related.
Comment #3
mikeryanOK, the front page was a red herring - with views enabled, I have no front page problems but I still get the process interrupted. I've reduced the user table I'm migrating from so it fits in one batch, but what is happening now is that the next migration (d6_node_type) hangs and ultimately fails when *it* goes to a second batch. Logging to dblog shows that when attempting to load the next batch after the user migration, it goes into a loop reloading the batch page _batch_page() repeatedly. Each time this calls \Drupal::service('batch.storage')->load($request_id) (with $request_id == 2, which exists in the batch table) and the load fails. BatchStorage::load() looks up by both the request ID and by csrf_token - I don't know how/where that token is generated and provided, but I'm betting that saving the admin account changes it. Hmmm, I wonder if you edited the account manually in a separate tab while a batch is running if it would have the same effect... Also, symptomatically this issue recalls #2508888: Fatal error during batch operations causes endless test loop - the fix there seems unlikely in this case, but it may be worth a shot for completeness.
Comment #4
mikeryanYep - changing the user migration back to skipping uid 1, if while migration is running I change the admin user's password in a different tab it hoses the batch processing, because a password change causes the session to be recreated. I expect this will happen with any batch processing, not just migration - I'll open a batch system issue for that, but will not be optimistic about a fix in the forseeable future.
In the meantime, it's arguable whether migration should change the admin user's password - you've just created this D8 site with a given admin password, don't you expect that password to continue to work after migration? I think the user destination should not alter the admin password anyway.
Comment #5
mikeryanOpened issue against the batch API at #2607478: Batches broken by password change.
My original thought was that it would be hard to fix this while maintaining CSRF safety, but then it occurred to me that User::postSave() could fix up the batch table. Need some discussion about whether to pursue that for 8.0.0, or as suggested above have EntityUser::import() make sure the admin account password isn't changed.
Comment #6
mikeryanComment #7
mikeryanPursuing the skip-admin-password approach, here's a test-only patch.
Comment #8
mikeryanWith the fix. Note this requires adding a method removeDestinationProperty() to the Row class, which seems sensible.
Comment #12
mikeryanThe existing D6 user migration test was expecting the admin password to be migrated, changed to only test non-admin passwords.
Comment #14
mikeryanOK, ready for manual review.
Comment #15
mikeryanComment #17
wim leersNit: s/Remove/Removes/
Don't we usually say "root"?
C/P remnant.
string[]string[]"conform the Drupal 7" sounds strange. s/the/to/ ?
Comment #18
mikeryanAll feedback addressed, thanks!
Comment #19
phenaproximaLooks good, but two minor things --
I don't think we need to check if the 'pass' property is set. Let's just unconditionally kill it if it's uid 1.
We're tagging test migrations now? :)
Should be $this->executeMigration($migration)
Comment #20
mikeryanAs we have been, yes. The strict schema checking insists migration_tags be set - if it's there anyway, no reason not to put a value in.
Other requested changes have been made.
Comment #21
quietone commentedTested and confirmed this works. Since phenaproxima and Wim Leers have looked at this, I'll RTBC.
Comment #23
webchickThis seems to be isolated to Migrate so should be RC eligible. Also gets the UI working again, which is fantastic.
Committed and pushed to 8.0.x. Thanks!
Comment #24
webchickOopsie, credit.