Hm, this doesn't look right to me... It seems like this change prevents IP address blocking from working on update.php altogether?
We can turn it off during the D6->D7 upgrade, but once someone is running full D7, the IP address blocking should start working again (as was the case with the code that this replaced).
I wonder if something similar to the old method would work (try to bootstrap to the correct phase, then catch any exceptions)?
However, I seem to remember from another issue that exception handling in update.php isn't currently working correctly at all.... So possibly this issue is one we should return to later, once update.php is overall less broken.
@chx, this is a bug and an unintentional regression. Every page in Drupal has its own access control, and update.php is no different - but the intended behavior is that IP address blocking prevents the page from being bootstrapped or accessed in any way. This is how it works in Drupal 6, and how it worked in Drupal 7 before this issue.
It is possible that we can downgrade this from "critical" - it's hard to imagine a scenario where this would lead to total disaster. But it should be fixed.
Comments
Comment #1
damien tournoud commentedHere is a patch.
Comment #2
dries commentedCommitted. Thanks DamZ.
Comment #4
David_Rothstein commentedHm, this doesn't look right to me... It seems like this change prevents IP address blocking from working on update.php altogether?
We can turn it off during the D6->D7 upgrade, but once someone is running full D7, the IP address blocking should start working again (as was the case with the code that this replaced).
Comment #5
damien tournoud commentedHum. True, it does prevent IP address blocking from update.php altogether. I would be happy if someone can find another solution.
Comment #6
damien tournoud commentedThis is a blocker, now.
Comment #7
David_Rothstein commentedI wonder if something similar to the old method would work (try to bootstrap to the correct phase, then catch any exceptions)?
However, I seem to remember from another issue that exception handling in update.php isn't currently working correctly at all.... So possibly this issue is one we should return to later, once update.php is overall less broken.
Comment #8
chx commentedthere is no ACCESS in bootstrap anymore.
Comment #9
David_Rothstein commentedThis still valid... retitling to accurately reflect the current issue described above.
Comment #10
chx commentedrgrep BOOTSTRAP_ACCESS *
chx@veyron:/var/www/drupal$
Comment #11
David_Rothstein commentedBetter :)
Comment #12
chx commentedupdate has its own access control.
Comment #13
David_Rothstein commented@chx, this is a bug and an unintentional regression. Every page in Drupal has its own access control, and update.php is no different - but the intended behavior is that IP address blocking prevents the page from being bootstrapped or accessed in any way. This is how it works in Drupal 6, and how it worked in Drupal 7 before this issue.
It is possible that we can downgrade this from "critical" - it's hard to imagine a scenario where this would lead to total disaster. But it should be fixed.
Comment #14
catchDowngrading, would be nice to fix. Would be nicer to remove ip address blocking from core 'cos it's a big mess.
Comment #15
trevorleenc commented#1: 583008-kill-bootstrap-access.patch queued for re-testing.
Comment #17
Celine Bessa commented#1: 583008-kill-bootstrap-access.patch queued for re-testing.