[jayd16]

Seems awful to me. Why would you ever have unprotected queries and leave security holes sitting around for you to forget to "Simon says, protect()"?

Wouldn't a better system be authorization fully baked through and then service accounts and at most a dummy auth provider for unit tests and maybe local dev?

Instead of selecting the world and throwing things away, why don't you just optional join a protected table (or view even) when needed?

Am I crazy?

[jussinevavuori]

Thank you for the comment. This is not what I'd intended to communicate with this article. The Kilpi.filter pattern is not the primary point of this article, it is only a minor utility provided by Kilpi for special cases.

My point was to show how you can co-locate your queries and authorization logic, just as you would with any sensible data access layer. This method however keeps the inner function pure and easily cacheable, e.g. with the upcoming "use cache" Next.js directive, and allows easy explicit bypassing of the protection with e.g. `.unsafe()`, which is required in some scenarios in your application.

I hope this clarifies my intent.

[clintonb]

You're not crazy, but you assume everyone starts with security in mind. That is definitely not the case.