[BUG] Thredds Deny Recursive permission not working as intended on "old upgraded" server.

[tlvu]

Describe the bug I am not supposed to be able to browse this link https://pavics.ouranos.ca/twitcher/ows/proxy/thredds/catalog/birdhouse/testdata/secure/catalog.html?dataset=birdhouse/testdata/secure/tasmax_Amon_MPI-ESM-MR_rcp45_r2i1p1_200601-200612.nc since the path "/birdhouse/testdata/secure" has "Deny, Recursive" permission set on it.

On only that, I was able to download the .nc raw file. The only path that actually has a "Deny, Recursive" permission working is "Opendap" path on that file. All other paths I can access.

Jenkins was passing on production server all this time because the notebook only checks for the Opendap path and the Opendap path is the only path being "denied" as expected.

The weirder problem is I deployed a fresh server on the exact same birdhouse-deploy commit and "Deny, Recursive" was able to block everything, ex: https://lvu8.ouranos.ca/twitcher/ows/proxy/thredds/catalog/birdhouse/testdata/secure/catalog.html?dataset=birdhouse/testdata/secure/tasmax_Amon_MPI-ESM-MR_rcp45_r2i1p1_200601-200612.nc (exact same file, just fresh server).

So it seems that on a production server where we have done many DB upgrades, some "cruft" is left behind and confused Twitcher/Magpie? Another difference is on the production server we have 800+ users whereas my fresh test server only has 3 users (admin, anonymous, authtest).

Found accidentally when testing for https://github.com/bird-house/birdhouse-deploy/pull/478.

To Reproduce Steps to reproduce the behavior: Deploy the stack at this commit https://github.com/bird-house/birdhouse-deploy/commit/eefea6145f611d471f922d96f7f156272a027e2f

Expected behavior Should get "Access to service is forbidden" for this link https://pavics.ouranos.ca/twitcher/ows/proxy/thredds/catalog/birdhouse/testdata/secure/catalog.html?dataset=birdhouse/testdata/secure/tasmax_Amon_MPI-ESM-MR_rcp45_r2i1p1_200601-200612.nc

Screenshots Correct behavior on my fresh server

Wrong behavior on production server

Magpie config on production server is properly set to "Deny, Recursive"

Desktop (please complete the following information):

• OS: Linux
• Browser: Firefox
• Instance: https://pavics.ouranos.ca
• Version "3.38.0"

[fmigneault]

I'm running the same server version 1.42.2 and Magpie 3.38.0 on Hirondelle, and the following causes the expected "Access to service is forbidden." response:

https://hirondelle.crim.ca/twitcher/ows/proxy/thredds/catalog/birdhouse/testdata/secure/catalog.html

Attempting the download via https://hirondelle.crim.ca/twitcher/ows/proxy/thredds/fileServer/birdhouse/testdata/secure/tasmax_Amon_MPI-ESM-MR_rcp45_r2i1p1_200601-200612.nc also causes the forbidden access.

What does the thredds service custom-configuration look like?

Also, check if the anonymous user has any "allow recursive" applied. User permissions would override the group permissions.

Those are the only thing I can think of that would cause different behaviors.

[tlvu]

What does the thredds service custom-configuration look like?

Also, check if the anonymous user has any "allow recursive" applied. User permissions would override the group permissions.

[fmigneault]

What happens if you click the ❔ button. Is it ❌ or ✅ ? This is supposed to do the same function call that Twitcher will do to resolve the request.

[tlvu]

What happens if you click the ❔ button. Is it ❌ or ✅ ? This is supposed to do the same function call that Twitcher will do to resolve the request.

[fmigneault]

Ok. That's really weird. All seems correct. I guess you will need to enable DEBUG logs (both Twitcher and Magpie, in both their respective INI files) and check the permissions being resolved when doing the request to see what is actually happening. I don't know what to investigate because I cannot replicate on my end.

[tlvu]

I guess you will need to enable DEBUG logs (both Twitcher and Magpie, in both their respective INI files)

OK. I will also try to replicate the Magpie DB from prod to my test VM that is currently fresh and do not have the bug. If I can reproduce the error on my test VM, this means the trigger for the bug is in the DB data and not in the code, or rather the code did not handle a special case on data that has been upgraded multiples times.