drupal-with-nginx icon indicating copy to clipboard operation
drupal-with-nginx copied to clipboard

404 ajax errors with taxonomy auto-completion

Open accuraz opened this issue 9 years ago • 17 comments
trafficstars

I'm on a full https d7 install and I use the auto-completion widget for my tags within node creation form.

Every time Drupal uses ajax for auto-completion I'll get a 404 ajax error.

I don't find any solution or references about that.

Can someone help me out please ?

Just tell me what information you need. I can give you the incriminated ajax call or anything else.

Thanks.

Regards.

accuraz avatar Feb 07 '16 06:02 accuraz

Which version of Drupal 7 do you have installed? In 7.42 this issue was fixed. Also, take a look at this tread

iryston avatar Feb 07 '16 11:02 iryston

Same issue after updating to 7.42

okolobaxa avatar Feb 07 '16 14:02 okolobaxa

I use Drupal 7.42

accuraz avatar Feb 07 '16 16:02 accuraz

I confirm, this regression appears after update to 7.42

An AJAX HTTP error occurred.
HTTP Result Code: 404
Debugging information follows.
Path: http://www.example.com/index.php?q=taxonomy/autocomplete/field_tags
StatusText: Not Found
ResponseText: 
404 Not Found
404 Not Found
nginx

On my sites I use Autocomplete Deluxe without error. It is core autocomplete problem.

As a temporary fix you can roll back this update by changing /includes/form.inc

- $element['#autocomplete_input']['#url_value'] = url($element['#autocomplete_path'], array('absolute' => TRUE, 'script' => 'index.php'));

+ $element['#autocomplete_input']['#url_value'] = url($element['#autocomplete_path'], array('absolute' => TRUE));

iryston avatar Feb 07 '16 16:02 iryston

@iryston Thanks for the temporary fix but the fix included to drupal 7.42 is a security fix, isn't it ?

accuraz avatar Feb 07 '16 16:02 accuraz

No, it is not security fix. To keep Drupal core as is, edit your Nginx config as described in this comment But, I don't think that allowing direct access to index.php is more secure.

iryston avatar Feb 07 '16 17:02 iryston

I think you're right about giving direct access to index.php I also read the comment append with the changes into form.inc and I realize it's not a security fix. Thanks

accuraz avatar Feb 07 '16 17:02 accuraz

@iryston Autocomplete Deluxe is a good solution for node add/update forms, but on view exposed filters it doesn't help.

My temporary solution is to add $attributes['value'] = str_replace("index.php?q=", "", $attributes['value']); to line 4025 in form.inc

okolobaxa avatar Feb 07 '16 18:02 okolobaxa

May be allow direct access to index.php if URL contains "/autocomplete/"?

okolobaxa avatar Feb 07 '16 18:02 okolobaxa

Sorry I came out a little late but I've an hudge agenda. I go trough drupal.conf and drupal_bootst.conf of the master branch and the only internal directives I wound was for private files system

## Trying to access private files directly returns a 404. location ^~ /sites/default/files/private/ { internal; }

I just start to use @perusio's config with dev servers because I wanna migrate from wordpress to drupal so I maybe miss something there. The question is why internal directive poses problem knowing that its only used for Drupal private files system ?

accuraz avatar Feb 08 '16 06:02 accuraz

Hi everyone, so is there a consensus on what the safest way is to modify @perusio 's config to work around this?

geckolinux avatar Feb 10 '16 12:02 geckolinux

I ran into this today using autocomplete from Entity reference.

Currently using chellman's fix until something gets updated over here.

mustanggb avatar Feb 12 '16 11:02 mustanggb

Thanks @akamustang for confirming that Chellman's fix works. Is there any security risk with allowing access to index.php?

geckolinux avatar Feb 12 '16 18:02 geckolinux

There are at least two solutions in the discussion posted by @akamustang https://www.drupal.org/node/2599326. I've confirmed that #30 (chellman's) works as does #49 (custom module) Relative merits are discussed there too.

norwegianblue-nz avatar May 22 '16 21:05 norwegianblue-nz

This fix worked for me: https://github.com/perusio/drupal-with-nginx/pull/261/commits/124a612920b6fe1a7170d6176647801993266bec

Note of caution to anyone who is new to nginx (as I am). Location blocks that select based on regex (as this fix does) are executed in the other they are defined in the config file. Depending on your config file, placing it in the same location as this patch might not work. In my case, other location blocks were overriding the rewrite in this patch. It worked once I put it immediately above .

## Any other attempt to access PHP files returns a 404.
location ~* ^.+\.php$ {
    return 404;
}

CindyConway avatar Sep 27 '16 23:09 CindyConway

To prevent allowing direct access to index.php is written a little module Autocomplete Unblock The sandbox project is located at https://www.drupal.org/sandbox/irystonnet/2821464

Opened issue on Drupal.org Project applications https://www.drupal.org/node/2821473

To use it just clone to modules directory and enable.

git clone --branch 7.x-1.x https://git.drupal.org/sandbox/iryston.net/2821464.git autocomplete_unblock

iryston avatar Oct 24 '16 20:10 iryston

@iryston 's module works great, thanx a lot!

bardachev avatar Apr 04 '18 12:04 bardachev