J'ai besoin de quelques opinions.Utilisation de Postgresql comme couche intermédiaire. Besoin d'avis
Je vais développer un logiciel POS et d'inventaire pour un ami. C'est un projet à petite échelle d'un seul homme donc je veux rendre l'architecture aussi simple que possible. J'utilise Winform pour développer l'interface graphique (l'interface Web n'a aucun sens pour le logiciel POS). Pour la base de données, j'utilise Postgresql. Le programme contrôlera l'accès en fonction des rôles des utilisateurs, donc je dois développer un niveau intermédiaire, en utilisant un serveur web, pour contrôler l'accès des utilisateurs ou simplement définir les privilèges des utilisateurs directement dans Postgresql. Le développement d'un niveau intermédiaire prendra du temps et la maintenance sera plus complexe. Je préfère donc définir le contrôle d'accès directement dans la base de données.
Maintenant, il semble que l'utilisation de la base de données pour contrôler l'accès utilisateur est problématique. Je dois définir des privilèges pour chaque rôle. Sans oublier que pour certaines tables, les privilèges sont au niveau des colonnes. Cela rend le raisonnement sur la sécurité très difficile.
Donc ce que je fais maintenant est de mettre toutes les tables à inaccessible, sauf par les superutilisateurs. Le programme se connectera à la base de données en utilisant un rôle public. Parce que les tables sont inaccessibles par public, je vais rendre les fonctions stockées accessibles au public avec SECURITY DEFINER (avec le rôle de superutilisateur). La seule façon d'accéder aux tables est d'utiliser ces fonctions.
Je vais mettre les rôles d'utilisateur et les mots de passe dans un tableau. Parce que la table d'utilisateur elle-même est inaccessible par non-superutilisateur, je vais faire une fonction de connexion, appelons-le fn_login(username, password). fn_login renverra une clé de session si la connexion est réussie. Pour appeler d'autres fonctions, nous devons fournir une clé de session pour l'utilisateur, par exemple: fn_purchase_list(session_key), fn_purchase_new(session_key, purchase_id, ...).
Ainsi, je traite les fonctions stockées comme des API. L'ajout d'un nouvel utilisateur sera plus facile car j'ai seulement besoin d'ajouter de nouvelles lignes dans la table utilisateur plutôt que d'ajouter de nouveaux rôles Postgresql. Je n'aurai pas besoin de définir des privilèges au niveau de la colonne. Tous les contrôles seront effectués par programme.
Alors, qu'en pensez-vous? Cette approche est-elle faisable et évolutive? Y a-t-il une meilleure façon de le faire?
Merci!
Toutes les applications n'ont pas besoin d'être mises à l'échelle. La technologie client/serveur des années 90 est plus que viable pour de nombreuses organisations. Depuis le simple fait que les grandes organisations ont réussi à utiliser la technologie est indicative qu'elle était efficace. Peut-être pas optimal, mais au moins réalisable. Et probablement, cette application n'est pas près d'avoir ces problèmes. Bien sûr, il y a des limites, c'est une considération de conception comme toute autre chose. –
Mais le questionneur a spécifiquement demandé: «Cette approche est-elle faisable et évolutive? Réalisable? Bien sûr. Évolutif? Cela dépend de jusqu'où il faut aller, et il n'y avait aucun indice à ce sujet. – duffymo
Eh bien, j'ai lu "un projet à petite échelle d'un homme, donc je veux rendre l'architecture aussi simple que possible" et je me suis dit que cette question avait déjà été résolue. –