Hi to all,
I provided a patch for the webform module here (version 7.x-4.22, I am working with Drupal 7.69), and am trying to provide a test with it.

My issue is the following : the patch I provided fixes a 500 error I was getting when getting a certain page (namely, /node/mynid/webform-results/table?sort=asc&order=myfieldid). The test I  am trying to provide to go along with it should fail when the patch is not applied (ie. detect the page returns a 500).

In order to prove that, I am creating some a webform node, some submissions to it, and using drupalGet() on the said URL. However, not only does the page not return a 500 erorr, but more importantly when I tried passing a gibberish URL in the testing code (for example, /node/mynid/webform-eqzrvsijekvnzejkvdsvkw) the test passes. Did I miss something setting up my test ? Is this a known issue ? What should I do to circumvent that behavior ?

Thanks for reading me.

My testing code is below :

  public function testWebformSubmissionSort () {
    $path = drupal_get_path('module', 'webform');
    module_load_include('inc', 'webform', 'includes/webform.submissions');
    $this->webformReset();    

    // Create a new Webform test node
    $this->drupalLogin($this->webform_users['admin']);
    $node = $this->webformForm();

    // Submit some sample values
    $this->webformSubmissionExecute('sample');
    $this->webformSubmissionExecute('sample');

    // Get the cid of the interger component.
    foreach ($node->webform['components'] as &$component) {
      if ($component['form_key'] === 'integer') {
        $integer_cid = $component['cid'];
        break;
      }
    }

  // Navigate to the result table, and sort results by the integer field 
  $integer_field_name = $node->webform['components'][$integer_cid]['name']; 
  $this->drupalGet('node/'. $node->nid . '/webform-results/table', array('query' => array('order' => $integer_field_name))); // this line returns 200 even with a gibberish URL, ex /webform-xdvsfjvfsdf


   // Assert the page is loaded correctly 
   $this->assertResponse(200, t('The HTTP response was 200 for the result table sort page.'));
   $this->drupalLogout(); 
  }

Comments

jaypan’s picture

With the way Drupal (7) parses URLs, it will match as much of the path as it can. so in your case, because node/nid returns a value, /node/mynid/webform-eqzrvsijekvnzejkvdsvkw will return the value of /nid/nid.

This is a known issue and I believe fixed in Drupal 8. I also remember seeing a module or a patch around to throw 404 errors for this situation (which wouldn't be a 500 error anyways, which is when the page is broken, you should be expecting a 404 - page not found).

Contact me to contract me for D7 -> D10/11 migrations.

theolem’s picture

Thanks a lot for your answer, I understand better know. If you ever come across the module you were talking about I'd be interested.

If you have experience with this, would you advise to test the content of the page rather than the URL to make sure the right page was loaded ? HTML content ?

john_b’s picture

Completely off topic,  the question reminds that me that this week I saw a denial of service attack coming from AWS in USA where a very long search query on a site using Solr was called, only a few times a minute. PHP-FPM was crashing. The query returned 200 of course, with no results. As far as I know Drupal 7 has no way to handle such an attack.

Since the attacker was using multiple IPs and multipe user agents, it was not easy to block that way. We were running our own server, so I added a regex in the nginx config to return 403 if the GET request started /search and was above an arbitrarily chosen number of characters.

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors