Problem/Motivation
The function jquery_update_library_alter() uses the POST variable $_POST['ajax_page_state']['jquery_version']. We should always treat POST variables with suspicion.
Proposed resolution
The core function ajax_base_page_theme() (in includes/ajax.inc) does this check:
$token = $_POST['ajax_page_state']['theme_token'];
if ($theme === variable_get('theme_default', 'bartik') || drupal_valid_token($token, $theme)) {
return $theme;
}
Let's do something similar here.
Remaining tasks
User interface changes
None
API changes
None
Data model changes
None
| Comment | File | Size | Author |
|---|---|---|---|
| #11 | 3317298-11.patch | 4.66 KB | mcdruid |
| #8 | jquery_update-3317298-8-test-only.patch | 2.57 KB | benjifisher |
| #6 | jquery_update-3317298-6-test-only.patch | 4.78 KB | benjifisher |
Issue fork jquery_update-3317298
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #3
benjifisherEven though the changes are pretty small (+10/-2) I think they are easier to understand as a series of small commits, so I opened a MR for this issue.
I confess that I have not tested this at all, except that I installed the module and did not get a WSOD. Testing is the reviewer's job, right? ;)
Comment #4
mcdruid commentedThanks, I think this looks pretty good but in the absence of tests it's a bit hard to know for sure!
We have started adding tests recently but there's nothing that would cover this functionality yet.
I think we should probably check whether this element exists before using it to avoid PHP warnings etc.. (keeping in mind that we need to use e.g. the traditional long-winded ternary syntax etc.. if that's the approach we took).
Comment #5
benjifisherGood points in #4.
I did the easy part, adding a check for
!empty(...)before using the POST variable. If the check is to provide any protection, we have to ignore the jQuery version in the AJAX request unless it comes with a token.This means we have to invalidate any cached pages that have set
jquery_versionbut notjquery_version_tokenin Drupal.settings. Can we just advise site owners to clear caches when upgrading to the next release, or do we have to write an update function?I may not have time today to add anything to the tests. I do not see any AJAX tests in the module, but maybe I can use
ajax.testin the coresimpletestmodule as a guide.Comment #6
benjifisherI struggled for a while, trying to come up with an integration test. If you really want, then I can keep trying.
What I have now is more like a unit test. It directly calls
jquery_update_library_alter()three times: the second time, it setsjquery_versionin a POST variable, and the third time it also sets a token in a POST variable.That is not ideal. Since this is really a functional test, not a unit test, the alter function is already applied in the first line. So these assertions are redundant. I could leave out the second set of assertions, or I could replace the first line with an explicit array. The second option would make it more like a unit test.
Maybe, instead of altering the same
$librariesvariable three times (since it is passed by reference to the alter function) I should do something likeI am attaching the new commit as a test-only patch. I expect it to fail when applying the alter function with just
jquery_versionset in the POST variable (two assertions).Comment #8
benjifisherI broke a long line in order to keep CodeSniffer happy.
Here is a version of the test-only patch that includes that fix and also removes some WIP changes that I accidentally included in #6.
The testbot will set this issue back to NW because of the test-only patch.
Comment #10
benjifisherComment #11
mcdruid commentedNeeded a reroll after #3317322: jQuery version for theme not loading as selected if custom path is set added to
jquery_update.test.I am happy with this patch if the testbot is.
Comment #13
mcdruid commentedThanks @benjifisher!