Άυτό δεν το κατάλαβα. Security οριζόντια εννοείς μάλλον το row-level security. Πώς δένει αυτό με το string από IDs? Και τί εννοείς ο "default" τρόπος?

Για την ιστορία, η Oracle υποστηρίζει row-level security αλλά στην ουσία κάνει join τα RowIDs κάθε πίνακα με ένα "function" το οποίο ελέγχει τα permissions. Αν αυτά είναι απλά UserID, RoleID θα μπορούσε άνετα να κάνει join με ένα πίνακα που θα περιέχει RowID, AllowedUserID, AllowedRowID. Ο πίνακας αυτός μπορεί να περιέχει πολλές εγγραφές, αλλά δεν μας πειράζει. Μια DB τα πάει πολύ καλά με πολλές εγγραφές φτάνει να έχουν indexes.

Παρόμοια λύση είχα εφαρμόσει και σε αυτή την περίπτωση, μόνο που εκεί έπαιζαν και ιεραρχικά permissions (ιεραρχικά ανά business unit, ρόλο), τα οποία συμμετείχαν σε όλα τα queries που επιστρέφανε πληροφορίες στο χρήστη (δηλαδή σε grid, show και edit φόρμες).

Ναι, μιλάω για το row-level security.

Παναγιώτη, το match 1 χρήστη με 1 RoleID δεν αποτελεί πραγματικότητα. H ιεραρχία μέσω Roles, Subroles και User groups για την γρήγορη κατανομή, είναι πιο ρεαλιστικός τρόπος. Μόνο εδώ στο forum το match του χρήστη με το ποιο forum μπορεί να δει, κάνει post, να στείλει ένα αρχείο μαζί με το μήνυμα, είναι πολύ πιο πολύπλοκο.

Το RowID, AllowedUserID, AlllowedRowID μπορεί να φαίνεται καλός συνδιασμός, αλλά δεν δουλεύει για ν-δυναμικό αριθμό χρηστών, Πως θα υλοποιηθεί; Θα κάνω ένα "trigger" μέσα στην βάση ή στο Bussiness layer και θα προσθέτω μια εγγραφή κάθε φορά που μπαίνει μια εγγραφή μέσα στον πίνακα; Και όταν αλλάξω τα δικαιώματα σε ένα χρήστη προσθέτωντας ή αφαιρώντας ένα Role θα εξετάζω όλα τα δικαιωματά του; Δημιουργώ ένα forehead load που δεν χρειάζεται.

Συνήθως χρησιμοποιήται ένα store procedure, που εκτελεί ένα role παρόμοιο με την Oracle, που ουσιαστικά είναι μια λίστα από IDs που εφαρμόζονται μέσα από ένα IN στο WHERE.

George J.

George J. Capnias: Χειροπρακτικός Υπολογιστών, Ύψιστος Γκουράρχης της Κουμπουτερολογίας w: capnias.org, t: @gcapnias, l: gr.linkedin.com/in/gcapnias