Currently I’m building a CSV Data Tables UI driven utility. This will allow upserting from CSV, inserting from CSV, formatting validation, etc… Which will be free to use once complete
Currently, access for forms is all or nothing, with no way to specify particular forms with particular permissions:
What I’m proposing is that in this area of the data table, we get access to specifying particular forms with particular permissions.
In my case, it’s because I want to utilize my CSV data table management tool to be able to manipulate data in any table.
I know I can’t have been the only one to build management tools for anvil, only to have to stuff them in another app.
I’m not familiar with the internal workings of the Anvil security model really so I wouldn’t know.
I assumed that this statement from the docs " Anvil intends to provide an intuitive security model. The basic principle is, “If you can see it, you can use it” . This is more formally known as a capability system ." Means that if you expose visually to the user, then they can access it.
What I’m proposing would basically be don’t have any links or UI that references the management UI, and could only be run by devs by changing the app startup form to run it, or to login to the app as a developer which gives you special access.
So any user of the app can access any form? Seems like a big security flaw.
If so, I’d need to rethink this, because I’d only want devs of the app to have access to it.
My apps for devs have access to dev stuff, my apps for less cool users have access only to stuff for less cool uers.
In order for a form to have access to a table, the browser needs access to a table, and when the browser has access to a table, any hacker has access to that table, without even passing through the form.
If you want to make something polished, then your form should use server calls to access the table, not use direct access.
If you want to do something quick, then your form should only be used by admin with full access apps.
Also, I have demonstrated Server-Side routing here which relies on server to return forms. You can try to build something like that. Although unless you want the additional benefits that it provides, I will suggest sticking to the above advice
Maybe there should be a “Developer Only” form feature. Where standard users don’t have access to creating it, and only developers can create and use it for management purposes of the app.
The form can do self.container_1.visible = True and show anything. That code can be written on the browser console, the fact that you don’t write it doesn’t mean that it will not work. (you can’t really open the console and write that code, because the console speaks Javascript, not Python, but any decent hacker can do that).
Similarly if the code in the form can do app_tables.my_table.delete_all_rows(), then any hacker can do that.
It’s good for rapid prototyping, when you work on a proof of concept, or when you learn.
It’s definitely not good for safe production apps.
As I suggested earlier, I always transfer data via server calls, I never give access to the tables to a form.
When I teach people how to use Anvil I always start from there and I say “I’m going to show you something that is awesome and that you should never do, but it’s good to see that it works, so you understand how Anvil works”. If I’m talking to expert web developers they are surprised by how easy is to access the database and they do understand the safety concerns. If I’m talking to beginners, I show how it works and explain why it’s dangerous.
Yes, perhaps the documentation should mention a little more details here.
I think anvil is taking to stance of creating a completely open tool, starting as basic as possible and giving the user the maximum control. (Speculation more than knowledge)
And the community has developed tools so the anvil team didn’t have too.
But, agreeing with you and @stefano.menci , maybe there should be more warnings in the documentation for the ignorant, as I certainly was when starting.
This forum has been a great source of education though, so I’d hope people would read more before jumping in on a project.
Allowing forms to write to data tables is generally something you will not prefer (unless you are working with a group of people you completely trust). Although in many cases, it’s totally fine to let them view data tables.
Agreed, there are data tables that are perfectly safe to allow unrestricted reading from the client side. Validation tables, for example, e.g. a list of categories for the user to choose from.
I typically don’t allow reading even for those tables, preferring to use server functions, but I wouldn’t want to lose the ability to mark a table for client reading.
With the Accelerated Tables feature (now in public beta), read-only views have a decided advantage in performance and simplicity of coding. You’ll still want to exclude any sensitive columns from those tables; e.g., move them to their own “shadow” tables.
As others have said, creating a separate app (that shares the relevant Data Tables) seems a good solution to me. What difficulties have you run into with that approach, though, because I haven’t tried it yet myself?
Just to reiterate, the “see” here is not referring to whether something is displayed visually in the UI but rather whether something is accessible to client-side code more generally.
