Yes. It's a poor design. The UI shouldn't care about permission or visibility rules. Instead It should only take data and render tables based on their data+metadata. All the permission logic should be done in the API level based on the caller ID/context.
Re:A Real World React – Htmx Port
by Winsaucerer on Sunday October 16, 2022 @06:01AM
(#33222479)
Yep, I think there's wisdom in what you say here for good design. My point is (using a very simple example) that there are ways in which server side rendering offers some immediate security benefits that don't automatically come for an API+front end design.
I'm not sure about its performance, as I haven't done a great deal of testing, but another tool to achieve some of what you suggest (assuming I've understood you) is using RLS. E.g., using the obvious query, and relying on RLS rules to return only permitted data. You can similarly send the appropriate role with the query [1].
I also note with interest that Postgres 15 includes some improvements that might make this kind of approach even more viable:
"PostgreSQL 15 lets users create views that query data using the permissions of the caller, not the view creator. This option, called security_invoker, adds an additional layer of protection to ensure that view callers have the correct permissions for working with the underlying data."
Tbh, I’d prefer a runtime which would be itself aware of such metadata, knew the role out of a request/session context and could build a ui table based on all-columns-ever template, from a query automatically built for this specific case, because querying and throwing away totals may be expensive. This manual “do here, do there” is a sign of a poor platform (not that we have a better one) and code-driven rather than data-driven access control in it. Painting walls and installing doors every time you want a meeting should not be a part of a business logic, regardless of which-end and its implications.