Possible bug in pager when searching with contains

[dh]

The pager is producing page not found (presumably 404) errors when a "contains" search is in use.

Here's a database I have (no authentication) http://tbed.org/industry/index.php.

Now here's the pager set to page 2 with NO search specified:

http://tbed.org/industry/index.php?tablename=naics6_vw&function=search&where_clause=&order=id6&order_type=ASC&page=1

and here's page 2 when a search is specified

http://tbed.org/industry/?tablename=naics6_vw&function=search&where_clause=%28%60naics6_vw%60.%60title%60+LIKE+%27%25comp%25%27%29&order=id6&order_type=ASC&page=1

This one produces a page not found error, which goes to my site default 404.

Can you advise? Thank you.


You are using DaDaBIK version 8.0-Lerici enterprise, installed on 05-26-2017 (installation code: 0), the latest version of DaDaBIK is released on --

You are not running the last release of DaDaBIK, the release you are running might have bugs and security holes, see the official change log for further information. You can upgrade DaDaBIK here.

PHP Version: 7.0.19

mysql version: 5.6.35

Web server: Apache

Client: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/603.2.4 (KHTML, like Gecko) Version/10.1.1 Safari/603.2.4

 

[eugenio]

Hello,
I can't reach the site and I can't reproduce the bug on my side.
Question: did you fill $site_url and $site_path in config.php? If yes, leave them empty.

 

[dh]

Eugenio, there seems to be a network routing issue with my webhost that affects some global networks but not others. Maybe global cyberware has broken out!

You could try a proxy service somewhere outside Europe if you want to try again before it's fixed, but I can assure you no both $site_url and $site_path are already blank.

Does anything look malformed about the second URL? It reliably produces page not found on any network that can reach my host.

 

[eugenio]

Hello,
if you can publish the application where I can easy access it (both front-end and admin) I can have a look at it, otherwise I can't reproduce that bug on my side.

Best,

 

[dh]

OK, the application is set up for no authentication. I have disabled the .htaccess IP address controls for as long as it takes you to view and respond.

Front end http://tbed.org/industry/index.php
Admin http://tbed.org/industry/admin.php

Please let me know when I can reinstate the .htaccess lockout.

Thank you for your help .

 

[dh]

By the way, the pager bug DOES NOT appear with searches on "starts with" -- only with "contains"

 

[eugenio]

Hello,
the network connection to this site is still extremely slow and it is very difficult to debug the issue (I am getting ERR_CONNECTION_TIMED_OUT erros); from what I can see it seems to me more a network / Apache configuration issue than a DaDaBIK issue, an URL like this one:
http://tbed.org/industry/index.php?tablename=naics_vw&function=search&where_clause=%28%60naics_vw%60.%60title%60+LIKE+%27%25a%25%27%29&order=naics_id&order_type=ASC&page=1

for some reason is changed to :

http://tbed.org/industry/tablename=naics_vw&function=search&where_clause=%28%60naics_vw%60.%60title%60+LIKE+%27%25a%25%27%29&order=naics_id&order_type=ASC&page=1

(index.php removed) and that's the reason you get a 404 error. Is there any particular Apache rewriterule that can cause the problem? Can you try the same application on another machine?

Best,

 

[dh]

Thanks -- that makes sense. I can see the missing index.php.

My .htaccess in the site root directory is a mess, because it's been played with by Wordpress and W3 total cache over the years. I think I will go force a cleanup and simplify it.

And I will report the slow routing from Europe again. Can you possibly give me the traceroute from your IP to mine? I will provide that to my webhost.

I will now reinstate the IP address restrictions on the application directory.

Thanks again for your troubleshooting.

 

[dh]

Cleaning htaccess did not fix the issue. I have my webhost investigating Apache issues.

I'm beginning to wonder if this is a rewrite issue in php 7.0.

 

[dh]

No, setting back to php 5.5 had no effect on the spurious rewrite.

Also, including RewriteEngine Off in the application directory's .htaccess does not stop the rewrite.

 

[dh]

Eugenio, we've tried everything. Deactivated all WordPress plugins, killed caching, tried a simpler theme, but nothing affects the rewrite. Really nothing should, since Wordpress code should not affect a separate directory inside public_html with DaDaBik installed, especially with ReweriteEngineOff in that directory! It really seems unlikely to be an Apache or Wordpress issue since none of them even knows this directory exists.

So to summarize, the string prepared by the pager (I'm copying the URL from the pager item 3):

... LIKE+'ma%')&order=naics_id&order_type=ASC&page=2 parses fine, while

... LIKE+'%ma%')&order=naics_id&order_type=ASC&page=2 produces the unexpected rewrite that drops the index.php and then produces page not found, of course.

The URLs are identical in every respect up to the first %.

Does that suggest anything to you about the URL encoders/decoders in business_logic and how they interact with the pager code?

If I can't figure this out, I'm going to finally have to give up on DaDaBik after almost a decade!

 

[eugenio]

Hello,
It's the first time I see this behaviour and I would like to help you but since I cannot reproduce the issue on my side I need a working access to your application, otherwise I can't help.

I'll send you a traceroute via PM.

Best,

 

[dh]

I want to report that Eugenio worked with me on private message to resolve this issue. It appears that the issue was not a bug, but was connected to a rogue trigger on mod_security that was rewriting the URL to subtract the index.php part, resulting in a file not found error. These things are notoriously difficult to pin down, but asking my webhost to remove a suspicious trigger in mod_security seems to have solved the problem as far as both Eugenio and I can observe. I really appreciated Eugenio's dedicated support for his excellent product.

 

[eugenio]

Thanks a lot to you !