You are not logged in.
Pages: 1
I'd like to define some more tuned access rights than per table. Depending on the TSQLAuthGroup the user should only be able to select or edit X rows or X cols depending on a value of one cols or any other condition.
From what I've seen, you said in others threads and in the doc that I should use an interface based service for doing so.
Could i also do it by defining a custom authentification schema? Does this would be a good way for my purpose?
Thanks.
Offline
There are several diverse way of accessing a record and its fields from the ORM.
You could even access it from a complex SQL statement, even with a NoSQL database.
So there is only per-table access right by now.
Anything with a smaller granularity - per ID or per field/column - won't be feasible, with full safety.
This is a security feature: it is expected to have no leak nor workaround...
It will be over-complicated and difficult to test to add such a per ID or per field/column rights.
A custom authentication schema won't help.
The cleaner way of implementing it is really by defining a "persistence service", using interfaces, then you can have an exact knowledge of the data access scope.
Disable all remote direct ORM access (at least for most users), then use the "persistence service" to safely access the data.
Offline
Thanks for your fast and clear answer, we'll try this way then.
Offline
Pages: 1