Module doesn't work after check "Disable node access records"

I have an edge case with PbT too, with the same wierd result, but on an existing site.

• Only 1 access module in my configuration; PbT 2.14
• Installed PbT on an existing site, that had already some basic pages. some linked to a menu
• Then restricted page access by term for anonymous users for all basic pages
• Re-saved all basic pages, rebuild permissions, cleared cache multiple times, …

Expected

• 403 on all basic pages when browsing anonymously

Result

• 403 on basic pages NOT linked to the menu
• pages linked to the menu produced a 403 the first time the page is viewed, BUT the second and subsequent times the url is requested the restricted page is shown (iii)

Workaround 1 (temporary):

• I disabled 3 Drupal cache modules (big pipe, page cache, dynamic page cache).
• Pbt is then working correctly on all pages (but we need caching)
• Reenabled all cache modules
• The same problems reappeared

Workaround 2 (FIX !!):

• With all cache modules back on;
• Disconnected the failing pages from the menu
• That fixed the access permissions and set the correct grant for that page !!

I’m not a developer, but it looks like there are some (old) persistent permissions (probably in cache or cache context) that or not refreshed or overridden on save, cache clear or rebuild in some cases.

I'm having the same problem, but pages are not linked to any menu. Un-ticking disable node access records restores expected functionality, which is sad, as I like the idea of pages appearing in views even if user was not logged in (to encourage them to log in).

Yep I am experiencing the same issue. Unfortunately need the pages to be in the menu in order to show the content that we offer for authenticated users. Seems like for now there is no way to do this without disabling all caching which is not really an option.

Curious if this could be fixed by using an external caching service eg. cloudflare or something similar... Anyone tried it?

after disconnecting and re-connecting the page from/to the menu the permissions were refreshed.

you could try that (alltough it might not be an option to disconnect/reconnect pages everytime PbT for those pages permissions change).

You have mentioned PbT version 2.14 in post number #2. We are currently on version 2.19. There have been a few important patch releases. Please read the release notes. Have you tried the latest version?

For my site, upgrading to 2.20 seems to have fixed things.

I spoke too soon.

PbT 2.20 is installed.

When Disable node access records is ticked.
1 A non accessible item appears in the view
2 When clicked get an Access denied page
3 If return to view and click item again, item is displayed when an Access Denied should be.

If caches are flushed, situation returns to (1) and repeats Access Denied on the first attempt to access and the full content on subsequent.

On first attempt to access the page (when the Access Denied is returned) I get in the log:

RuntimeException: Failed to start the session because headers have already been sent by "/var/www/covid19/vendor/symfony/http-foundation/Response.php" at line 1290. in Symfony\Component\HttpFoundation\Session\Storage\NativeSessionStorage->start() (line 145 of /var/www/covid19/vendor/symfony/http-foundation/Session/Storage/NativeSessionStorage.php) #0 /var/www/covid19/docroot/core/lib/Drupal/Core/Session/SessionManager.php(164): Symfony\Component\HttpFoundation\Session\Storage\NativeSessionStorage->start() #1 /var/www/covid19/docroot/core/lib/Drupal/Core/Session/SessionManager.php(118): Drupal\Core\Session\SessionManager->startNow() #2 /var/www/covid19/vendor/symfony/http-foundation/Session/Session.php(57): Drupal\Core\Session\SessionManager->start() #3 /var/www/covid19/docroot/core/modules/big_pipe/src/Render/BigPipe.php(240): Symfony\Component\HttpFoundation\Session\Session->start() #4 /var/www/covid19/docroot/core/modules/big_pipe/src/Render/BigPipe.php(295): Drupal\big_pipe\Render\BigPipe->performPreSendTasks() #5 /var/www/covid19/docroot/core/modules/big_pipe/src/Render/BigPipeResponse.php(112): Drupal\big_pipe\Render\BigPipe->sendContent(Object(Drupal\big_pipe\Render\BigPipeResponse)) #6 /var/www/covid19/vendor/symfony/http-foundation/Response.php(374): Drupal\big_pipe\Render\BigPipeResponse->sendContent() #7 /var/www/covid19/docroot/index.php(20): Symfony\Component\HttpFoundation\Response->send() #8 {main}.

You are using the BigPipe module. We are not using it. You could try to disable it.

The problem is most probably linked to your module setup. May you have multiple access restriction modules, caching modules etc.

Please debug the issue for your needs and share the patch. I will happily review it and apply it, if it passes the tests and suits to coding standards.

I tried disabling bigpipe but the problem remains.

Also tried disabling internal dynamic page cache. No change.

I am no longer receiving the runtime exception error.

Using drupal console to put the site into dev mode (which I understand disable extra caches) the problem remains.

It really seems to be something caching the page (rather than another access control module), as on the first attempt to access after flushing caches the Access Denied error is returned as expected.

Any suggestions on another caching option I am missing somewhere?

I thought I would test this on simplytest.me with only pbt installed.

Works as expected until:
- Disable node access records is selected
- permissions rebuilt
- cache flushed

Then the same problem occurs : access denied on first attempt followed by access granted on reattempting.

I then disabled:
-bigpipe
-internal page cache
-Internal Dynamic Page Cache

And module works as intended.

Re-enable bigpipe, still works as intended.

Enabling Internal Page Cache or dynamic page cache breaks it.

Sorry if this is over-sharing - hopefully someone benefits.

Perhaps it would be good to add that these two caching modules need to be disabled in order to use disable node access records as it seems core enables them?

Hmm.. looks like we must remove nodes with access restriction via PbT from the page cache, if node access records are disabled.

tested this on simplytest.me with the same result.

@thinkemergency - if you want to show protected records in views, maybe try this:

• Select "views > Query settings > disable SQL rewriting"
• Leave all caching modules enabled (default)
• Leave the PbT "Disable node access records" unselected (default)

Setting "disable SQL rewriting" in views will override node permissions in views, making them shown in your list.

Thanks for reporting gentlemen. I have introduced the page cache kill switch for restricted nodes, if the node access records are disabled.

See PbT version 8.x-2.21: https://www.drupal.org/project/permissions_by_term/releases/8.x-2.21