Jump to content

Page auto-complete stopped working


MarkE
 Share

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.

Link to comment
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)

Link to comment
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

Link to comment
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.

Link to comment
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?

Link to comment
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."

Link to comment
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.

Link to comment
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/

 

Link to comment
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.

Link to comment
Share on other sites

  • 1 year later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...