Hide Topics/Webs, but permit INCLUDE/DBCALL

I'd like to lockdown and hide WikiApplication webs and other template content from end users and WikiGuests. Is there any way (natively or a plugin) for authenticating/permitting a DBCALL/INCLUDE whilst not allowing a direct view of the source topics?

I'm making the assumption that DBCALL/INCLUDE doesn't go anywhere near /bin/view, so in reality they could easily have separate permissions, with /bin/view being controlled via ALLOWTOPICVIEW/ALLOWWEBVIEW, and whatever mechanism renders DBCALL/INCLUDE could use a different variable?

-- JonMcCoy - 09 Mar 2024

I'll add that I'm using Nginx, and really don't want to do this via the web server, but via Foswiki.

-- JonMcCoy - 09 Mar 2024

Okay, having searched and searched, and then for the 3rd/4th time going through every extension, I've just found AutoRedirectPlugin, which appears to be designed to solve this issue. I'm testing it out now, hopefully will do what I need without having to go deeper into system.

https://foswiki.org/Extensions/AutoRedirectPlugin

-- JonMcCoy - 09 Mar 2024

I'll update this to confirm that https://foswiki.org/Extensions/AutoRedirectPlugin does solve the problem, though it'd be nice to have an ACL that permits include/DBcall, whilst blocking search results and other methods, though appreciate it's a complex issue as inline includes could circumvent this chain easily. My main need is to protect the business logic, so I need nearly all of the content in those topics rendering, but I don't want the mechanism/"code" being visible.

That all being said, there's cases such as rendering a contact list of employees and using fields like email and role, whilst only allowing HR staff to access the employee page itself and being able to see everything. At the moment, if a user can't see the page, they can't see the contact details either.

-- JonMcCoy - 15 Mar 2024

There is no other way to hide apps. Using AutoRedirectPlugin is the recommended approach.

-- MichaelDaum - 15 Mar 2024