After upgrading Drupal to 7.39

When i change a setting (any setting) in a view an AJAX error pops up:
An AJAX HTTP request terminated abnormally.
HTTP Result code: 200
Debugging information follows.
Path: ...
StatusText: OK
CustomMessage: The response failed verification so will not be processed.

I did some googling, apparently this is related to: https://www.drupal.org/SA-CORE-2015-003

I also double-checked this issue but it seems to be a different problem: https://www.drupal.org/node/1376686.

How to reproduce: goto admin/structure/views, "edit" a view, click on the title to change title => the error pops up & the form to change the title doesn't appear.

Somebody proposed to "fix this by adding the following function to your Ajax callback function: ajax_set_verification_header();"
But i'm unsure where i should do this in the views module.

I also tried installing jquery_update and setting the jquery version for admin pages to 1.7 (and clear cache) but this did not resolve the issue.

And I tried a different admin theme, but this also did not work.

CommentFileSizeAuthor
#3 views-2572117-urlIsAjaxTrusted.patch361 bytesSteven Jones
ScreenShot1324.jpg83.24 KBliezie_D
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

liezie_D created an issue. See original summary.

liezie_D’s picture

liezie_D CreditAttribution: liezie_D commented

I was able to avoid the issue by changing misc/ajax.js
commenting out line 185:
// return ajax.error(xmlhttprequest, ajax.url, customMessage);

Steven Jones’s picture

Steven Jones CreditAttribution: Steven Jones at ComputerMinds commented
Version: 7.x-3.11 » 7.x-3.x-dev
Status: Active » Needs review
Related issues: +#2595607: Passing wrong URL to ajax.url
FileSize
views-2572117-urlIsAjaxTrusted.patch361 bytes

We're seeing this issue when using views ajax and views load more to load in more pages via ajax. There are multiple ways for Views to inform Drupal that the views ajax path is 'safe' to include and process the data from it, we had the odd situation where someone had an HTTP proxy that was stripping off the Drupal header added in ajax_set_verification_header so we really needed the ajax path to get added to the whitelist of paths in Drupal.settings on the initial page request.

I've attached a patch that should do just that.

weseze’s picture

weseze CreditAttribution: weseze commented
Status: Needs review » Reviewed & tested by the community

We experienced the exact same problem with on of our clients running (what they claim to be) "default configured proxy/firewall software that a lot of big companies use".

The client was experiencing views listings not working when using exposed filter, sorting and pagers when the view was configured to reload via AJAX.

This patch fixed it instantly!

bburg’s picture

bburg
he/him
Location Washington D.C.
CreditAttribution: bburg at Forum One commented

I was bit by this today when a client's organization firewall as stripping out the header. +1

knalstaaf’s picture

knalstaaf CreditAttribution: knalstaaf commented

Had a client with the same issue (using Kapersky) - patch solved this. RTBC imo.

DamienMcKenna’s picture

DamienMcKenna
Location NH, USA
CreditAttribution: DamienMcKenna at Mediacurrent commented
Parent issue: » #2855120: Plan for Views 7.x-3.16 release

Per the 7.39 release notes, this appears to be the correct way of handling the change.

The Ajax system now validates URLs before making an Ajax request. Existing code which uses the Drupal Ajax API in any of the standard ways should continue to work after this update. In the event you have unusual Ajax code which does not work with Drupal 7.39, you can have your code manually validate the URL in one of two ways. Either add the URL to the "urlIsAjaxTrusted" JavaScript setting (see ajax_pre_render_element() for an example) or call ajax_set_verification_header() in the Ajax callback function to mark the current URL as trusted. Only do this for URLs that you actually trust; Ajax requests in Drupal should never be made to untrusted URLs.

Adding it to the queue for the next release.

DamienMcKenna’s picture

DamienMcKenna
Location NH, USA
CreditAttribution: DamienMcKenna at Mediacurrent commented
Status: Reviewed & tested by the community » Fixed

Committed (with an extra comment). Thanks!

Status: Fixed » Closed (fixed)

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