Allow wildcard path conditions

I don't know the state of this patch currently (we've continued to successfully use #24 on D9.5) and I have my doubts, given the maintenance of this project, that it will make it into production. However, I've discovered a worrisome bug when using the patch.

When you have more than 20 passwords set up, the interface becomes paged, which is normal. However, any wildcard page passwords you have setup that are on the second page are NO LONGER password restricted.

Looking through the code of the patch, one of the first additions is pulling from loadAllProtectedPages:

// Check all protected pages entries for path match including wildcards.
$all_protected_pages = $protected_pages_storage->loadAllProtectedPages();
foreach ($all_protected_pages as $protected_page) {
  if ($path_matcher->matchPath($file_path, $protected_page->path)) {
    $pid = $protected_page->pid;
    break;
  }
}

Unfortunately, the loadAllProtectedPages function contains a pager/limit for 20 items. Fine for listing the pages, bad for checking all of the passwords:

public function loadAllProtectedPages() {
 $results = $this->connection->select('protected_pages', 'p')
   ->extend('Drupal\Core\Database\Query\PagerSelectExtender')
   ->fields('p')
   ->orderBy('p.pid', 'DESC')
   ->limit(20)
   ->execute()
   ->fetchAll();

A quick fix for this, and you need one if your pages are now unprotected, is to just up the limit or even drop the pager completely. I ended up duplicating the loadAllProtectedPages function, calling it listAllProtectedPages, and using it where the results are called. I left alone all the references to loadAllProtectedPages in the patch and just removed the pager from that function.

I would add this to the patch, but again, I'm not sure where it stands given the merge request, etc.

Here's a patch for the latest dev based on #24

And here's a version based on my comment in #34, it adds a new function to the patch in #35 for listing the Protected Pages vs loading them.

I made some changes based on the test failures, so here's an updated patch for the latest dev based on #24. I'm not familiar with writing tests so you're on your own there.

This is an updated version of #36, based on my comment in #34.

I used patch #24 with version 1.4 of this module.
Now I updated the module to 1.6 but the patch can not be applied.

Could not apply patch! Skipping. The error was: Cannot apply patch https://www.drupal.org/files/issues/2020-05-19/2890122-24.patch

an suggestions ?

it seems to work with wildcards e.g. * and version 1.6, but the description hints from patch #24 are missing.
Please enter the relative path and its corresponding password. When user opens this url, they will asked to enter password to view this page. For example, "/node/5", "/new-events" etc.
I thought, that indicates that patch did not make it to the release...
Can someone confirm wildcards are supported with V. 1.6 ?

a quick look into the module code, it seems the patch mostly made it to V1.6, only the descriptions for wildcard usage seem to be missing.
can someone confirm this is the case?

@nojj, I haven't looked at V1.6, but I'd be surprised if these changes made it in unannounced. In any case, the latest patches - 38 & 39 - work with the latest dev version only.

@mxwright, thanks for your response.
in a local test with V1.6 it seems with wildcard * the protection is not applied.
regarding latest dev and patches: is the security issue fixed in V1.6 included in the latest dev?

@nojj, yes it looks like the security issue is addressed in both 1.6 and the latest dev.

so you are are using the latest dev with patch #39 in your current projects?
and is the security-fix what you describe in #34 or something else?

@nojj, here is the current state of things:

• v1.6 and 8.x-1.x-dev have the Drupal security update
• Patch in #38 updates the patch in #24 for the latest dev version
• Patch in #39 updates the patch in #38 with the fix for the issue in #34, which I think is necessary to address, and is for the latest dev version

I'm using #39 with the latest dev successfully on my projects

@mxwright thank you very much for the detailed explanation!
curious if this makes it into the stable release...

@mxwright did another test. coming from V1.4 with patch #24, I could successfully update to V1.6 (stable version) and then apply patch #39. And wildcards seem to work.
that would be nice, because DEV-versions of modules are not listed in Drupal for pending updates.

is eher an option to use the wildcards for a "section global password"
we would like to use one global password for all URL beginning with
/xxx/*
but have different passwords for individual urls with a more specific url like
/xxx/abc

at the moment if the password for /xxx/* is not accepted for urls like
/xxx/abc

if a different password is set to this urls

any ideas to solve this?