Jump to content
MarkE

Page auto-complete stopped working

Recommended Posts

Page auto-complete has just stopped working on my site. It is still working on my dev machine (with the same code) - I've copied the live database to the dev machine and it works there. All the other page-select methods work OK, so my temporary work-round is to change the selection method for the affected fields - but this is rather messy for fields where there are a great many pages to choose from.

Any ideas? I'm wondering if my hosting service might have changed something to do this, but I can't think what. There are no error messages or logs - the field is just unresponsive when I type into it.

I'd be most grateful for any clues or suggested lines of enquiry.

Share this post


Link to post
Share on other sites
1 minute ago, MarkE said:

There are no error messages or logs

Did you check your browser JS console as well? Keep an eye on the network tab as well (you can filter by XHR).

  • Like 2

Share this post


Link to post
Share on other sites
3 minutes ago, dragan said:

Did you check your browser JS console as well

I have now!

Failed to load resource: the server responded with a status of 403 ()

(for address ncorchards.co.uk/admin123/page/search/for?..........etc)

Share this post


Link to post
Share on other sites

Playing around with the url which gets the 403, it works until I get to the parameter 

&get={firstname}%20{lastname}%20-%20{email}

In other words, the following is not forbidden:

https://ncorchards.co.uk/admin123/page/search/for?&templates_id=64&status<2048&limit=50&format_name=autocomplete_list_members

but adding the &get=... parameter results in the 403

Share this post


Link to post
Share on other sites

Well, that's strange. Seems like your hoster prohibits a query with "get" (?).

When you said "logs": did you refere only to PW-logs, or also Apache logfiles? Check both.

You could also add ?get={firstname}%20{lastname}%20-%20{email} to any other PW page (FE + BE) and see if the same happens.

Share this post


Link to post
Share on other sites

It seems like its the %20 that's causing the problem - but it never has before - I wonder what they can have done. Nothing in any logs.

Share this post


Link to post
Share on other sites

Try posting the same URL but with the '%20's replaced with a '+'.

Have you - or the hoster - added any rules to the htaccess file, or enabled any security modules?

Share this post


Link to post
Share on other sites

It's not at all clear what's causing it. Removing the %20s or replacing them with + doesn't work. Here is a list of tests:

?abc=abc&get={xxx}%20{xxx}            - forbidden
?abc=abc&get={xxx}{xxx}                   - OK
?abc=abc&get=xxx%20xxx                - OK
?abc=abc&get={xxx}%20xxx              - forbidden
?abc=abc&get={xxx}+{xxx}                - OK
/search/for?&templates_id=64&status%3C2048&limit=50&format_name=autocomplete_list_members                               - OK
/search/for?&templates_id=64&status<2048&limit=50&format_name=autocomplete_list_members&get={firstname}        - forbidden
/search/for?&templates_id=64&status<2048&limit=50&format_name=autocomplete_list_members&get=firstname        - OK
/search/for?&get={firstname}           - OK

(%3C gets replaced by < in browser URL)

😬

I haven't touched .htaccess or any settings on cPanel. The .htaccess file on the live site just differs from the website because cPanel adds the php7.2 settings: 

# php -- BEGIN cPanel-generated handler, do not edit
# Set the “ea-php72” package as the default “PHP” programming language.
<IfModule mime_module>
  AddHandler application/x-httpd-ea-php72 .php .php7 .phtml
</IfModule>
# php -- END cPanel-generated handler, do not edit

# BEGIN cPanel-generated php ini directives, do not edit
# Manual editing of this file may result in unexpected behavior.
# To make changes to this file, use the cPanel MultiPHP INI Editor (Home >> Software >> MultiPHP INI Editor)
# For more information, read our documentation (https://go.cpanel.net/EA4ModifyINI)
<IfModule php7_module>
   php_flag display_errors Off
   php_value max_execution_time 120
   php_value max_input_time 480
   php_value max_input_vars 1000
   php_value memory_limit 128M
   php_value post_max_size 20M
   php_value session.gc_maxlifetime 1440
   php_value session.save_path "/var/cpanel/php/sessions/ea-php72"
   php_value upload_max_filesize 20M
   php_flag zlib.output_compression Off
</IfModule>
<IfModule lsapi_module>
   php_flag display_errors Off
   php_value max_execution_time 120
   php_value max_input_time 480
   php_value max_input_vars 1000
   php_value memory_limit 128M
   php_value post_max_size 20M
   php_value session.gc_maxlifetime 1440
   php_value session.save_path "/var/cpanel/php/sessions/ea-php72"
   php_value upload_max_filesize 20M
   php_flag zlib.output_compression Off
</IfModule>
# END cPanel-generated php ini directives, do not edit

Looks like I need to raise an issue with the hoster?

Share this post


Link to post
Share on other sites

Looks like my friendly hosting provider installed new security without telling the customers:

"This site is hitting a firewall security rule: COMODO WAF: URL Encoding Abuse Attack Attempt"

I got them to disable it, but I wonder whether others might hit the same issue? @netcarverDoes it raise questions about PW's use of url parameters?

Quote from hoster:

"We automatically update our firewalls with the latest security rules provided by multiple vendors to ensure they are as effective as possible."

Share this post


Link to post
Share on other sites

I have this problem on at least 2 sites, and i knew it was the security rules doing it.

We're migrating these off to VPS so hopefully it won't be an issue;

In the meantime we just don't use the custom field format for the display of the selected pages, and that fixes the issue because it doesn't use those params.

Share this post


Link to post
Share on other sites

Just noticed this post on the issues-repo that might happen to fix the above as it contains a space -> "+" mapping.

Untested, might be worth a shot.

Share this post


Link to post
Share on other sites

 

19 hours ago, MarkE said:

"This site is hitting a firewall security rule: COMODO WAF: URL Encoding Abuse Attack Attempt"

A quick search for this COMODO stuff returned this interesting result: https://help.comodo.com/topic-212-1-514-5943-.html

Apparently, you can fine-tune which rules to activate or not. Perhaps it's possible to narrow down the firewall rule*, and de-activate it on PW-admin pages / URLs. Whether your hoster allows this, is of course another question...

* I guess it's #950107 from https://www.netnea.com/cms/2016/01/17/most-frequent-false-positives-triggered-by-owasp-modsecurity-core-rules-2-2-x/

 

Share this post


Link to post
Share on other sites
7 hours ago, netcarver said:

Just noticed this post on the issues-repo that might happen to fix the above as it contains a space -> "+" mapping.

That's useful to know about, but my tests showed that a simple %20 -> + fix would still have got a 403. Exactly how the rule operates, and therefore what if any replacement might defeat it, is not clear to me.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...