Bonjour, 

Pour l'instant j'ai une application web avec une partie configuration (très limité) ne permet pas la suppression ou la modification de certains éléments de ma Base de données.

L'application web n'étant pas très sécurisé, je pensais créer une deuxième application "interface de configuration" (application bureau) avec un windows form ou WPF (je n'ai pas encore décidé, mais je pense partir sur une windows form pour des raisons de simplicité). 

Une fois, j'ai entendu parlé de scaffolding je voulais savoir si il m'était possible de l'appliquer ici ? et comment ?

(si quelqu'un un un lien avec un bon exemple d'utilisation) 

Je développe en VB.NET avec visual studio 

Je vous remercie pour vos réponses  

-
Edité par DeveloSt 30 mars 2021 à 9:27:45

Il est bien plus simple d'avoir une application Web sécurisée qu'une application "lourde" qui s’exécute en milieu hostile (la machine de l'utilisateur).

Tous les outils de scaffolding .NET fonctionneront aussi bien en Web qu'en client lourd.

Les outils étaient nombreux mais je pense qu'ils dû tous se recentrer sur EntityFramework.

Ex :

https://docs.microsoft.com/fr-fr/ef/core/managing-schemas/scaffolding?tabs=dotnet-core-cli

https://github.com/dotnet/Scaffolding

-
Edité par bacelar 30 mars 2021 à 10:24:32

Merci pour les liens, 

bacelar a écrit:

Il est bien plus simple d'avoir une application Web sécurisée qu'une application "lourde" qui s’exécute en milieu hostile (la machine de l'utilisateur).

Je pensais qu'une application lourde serait plus simple et efficace car seulement 2-3 personnes aurait accès à l'interface configuration seulement depuis leurs PC (local).   

Est-ce que tu as des conseilles à me donner pour sécurisée l'application web ? 

Pour l'instant l'application n'a aucune sécurité (Un mot de passe en claire depuis le BackEnd pour accéder dans un mode administrateur qui permet d'accéder à des affichages supplémentaires (consolidation, vue globale)).

Par exemple, actuellement tu peux accéder aux pages directement via l'URL DNS/Nom_de_la_page

Comment créer un mot de passe sécurisé ? 

Je pense qu'il y à beaucoup d'autres choses à mettre en place ?  

Edit : il y a une différence entre scaffolding et ORM ? 

-
Edité par DeveloSt 30 mars 2021 à 11:58:11

Même si vous faites confiance aux utilisateurs légitimes pour ne pas communiquer ni l'exécutable ni leurs identifiants, rien n'interdit un virus ou un cheval de Troie de faire leur oeuvre.

Les mécanismes d'authentification et d'autorisation sont pléthoriques, et c'est fonction de vos modèles de droits (par rôle, fédération, multi-critères, etc...).

C'est pas les outils qui manquent.

Si vous avez des notions de "rôles" ("qui permet d'accéder à des affichages supplémentaires"), ASP.NET dispose de mécanisme/framework qui permettent des autorisations et de la customisation d'affichage en fonction de rôle avec juste quelques lignes de configuration + une base de données dédiée.

>Comment créer un mot de passe sécurisé ?

Pourquoi avoir un mot de passe "sécurisé" ?

>Je pense qu'il y à beaucoup d'autres choses à mettre en place ?

Si vous utilisez les outils "clé en main" d'ASP.NET, ça se résume à quelques lignes de configuration et de bien suivre les pré-requis.

>Edit : il y a une différence en scaffolding et ORM ?

Un ORM est bien plus puissant car il permet de créer un modèle OBJET bien plus souple et puissant que de bêtes listes de POCO contenant un champ par colonne de la table.

C'est pour cela qu'un ORM peut assez facilement faire l'affaire pour du "scaffolding", en sous exploitant ses possibilités.

bacelar a écrit:

Même si vous faites confiance aux utilisateurs légitimes pour ne pas communiquer ni l'exécutable ni leurs identifiants, rien n'interdit un virus ou un cheval de Troie de faire leur oeuvre.

Je pensais justement que ce qui se trouve sur le net est plus facile à pirater :? 

bacelar a écrit:

C'est pas les outils qui manquent.

Si vous avez des notions de "rôles" ("qui permet d'accéder à des affichages supplémentaires"), ASP.NET dispose de mécanisme/framework qui permettent des autorisations et de la customisation d'affichage en fonction de rôle avec juste quelques lignes de configuration + une base de données dédiée.

Pour l'instant il n'y a pas vraiment de rôle dans l'application a l'exception d'un mode administrateur (tous le monde en admin à accès a toutes les données), mais c'est possible que dans dans le future on me demande peut être de créer des rôles. 

bacelar a écrit:

>Je pense qu'il y à beaucoup d'autres choses à mettre en place ?

Si vous utilisez les outils "clé en main" d'ASP.NET, ça se résume à quelques lignes de configuration et de bien suivre les pré-requis.

Je vais regarder le lien suivant : https://docs.microsoft.com/fr-fr/aspnet/core/security/?view=aspnetcore-5.0

bacelar a écrit:

>Edit : il y a une différence en scaffolding et ORM ?

Un ORM est bien plus puissant car il permet de créer un modèle OBJET bien plus souple et puissant que de bêtes listes de POCO contenant un champ par colonne de la table.

C'est pour cela qu'un ORM peut assez facilement faire l'affaire pour du "scaffolding", en sous exploitant ses possibilités.

L'utilisation d'un ORM dans une application ne nous rend pas dépendante à elle ? on peut continuer dans d'autres parties de l'application à faire des requêtes directement vers la Base de Données ?  

Les machines clientes sont "sur le net" pour accéder sur votre machine, non ?

Si vous utilisez un intranet verrouillé/fermé, vous pouvez avoir plus confiance dans les machines clientes, mais la sécurité est déporté vers l'infrastructure réseau.

Et dans ce cas, l'application Web ou Client lourd, au niveau sécurité, c'est la même chose.

Si vous avez déjà à distinguer ceux "qui permet d'accéder à des affichages supplémentaires" du reste, c'est déjà au moins 2 rôles, donc partez vers les mécanismes qui permettent de faire de l'autorisation par rôles, c'est beaucoup plus simple à gérer au jour le jour.

>L'utilisation d'un ORM dans une application ne nous rend pas dépendante à elle ?

Si c'est mal fait oui, mais en utilisant correctement une architecture en couche, il n'y a pas de problème particulier à l'utilisation d'un ORM.

Si votre application n'a pas de couche, c'est que c'est une application jetable, et par définition d'une application jetable : changer le moyen d'accès aux données == refaire l'application (qui n'a pas dû demander beaucoup de travail).

>on peut continuer dans d'autres parties de l'application à faire des requêtes directement vers la Base de Données ?

Oui, l'utilisation d'un ORM ne vous interdit pas de travailler comme un sagoin.

Il faut absolument que vous cloisonniez votre application pour le maintenir gérable, et avoir des requêtes à la base de données de partout, c'est le meilleur moyen pour avoir un machin un modifiable "simplement".

L'ORM est là pour vous permettre de facilement BIEN architecturer votre application, pas pour vous cassez les pieds.

Si vous travaillez comme un sagouin, l'ORM aura moins d'intérêts, voir jouera contre vous, si vous faites correctement les choses, l'ORM sera votre allié.

Si votre application est correctement architecturée pour utiliser correctement un ORM, passer à un autre ORM ou à une technologie plus puissante sera bien plus simple que si votre application est un amas informe de requêtes SQL dans tous les coins.

Je vous remercie pour votre réponse. 

Une dernière question sur les ORM, si l'on a besoin de faire des requêtes complexes (sous-jointure, variables incrémentées...) cela ne pose pas de problème ou ne complexifie pas le code ? (par exemple j'ai une requête qui réalise un classement des 3 plus grands scores par jours sur une plage de date) 

Justement j'envisage d'utiliser un Scaffolding/ORM pour la partie Configuration car il me faudrait faire de simple CRUD sur des tables (voir peut-être quelques jointures), mais les requêtes restent relativement simple. 

Ce qu'il faut absolument éviter, c'est d'avoir des requêtes SQL qui traînent un peu partout dans votre application, car les schéma de base de données c'est ce qui est le plus susceptible de changer au cours de la vie d'une application :

- changer de version du SGBDR

- changer de SGBDR

- optimisation par un DBA

- optimisation liée à la monté en charge

- optimisation liée à la nature des données effectives

etc...

En utilisant un ORM évolué, c'est lui qui se chargera de régénérer le code "glue" qui encaissera les changements de schéma.

Si vous avez un ORM/scaffolder rudimentaire, en limitant ces requêtes SQL qu'à la couche DAL (Data Access Layer), vous circonscrivez les impacts des modifications de schéma à cette DAL.

Si vous avez besoin de filtre "fonctionnel" comme des "3 plus grands machins par l'âge de la fille du capitaine", des ORM comme EntityFramework sont à même de générer des requêtes optimisées (utilisation explicite d'index, de statistiques de données, etc...) en collaboration avec les générateurs de plan d'exécution du SGBDR. Après, si vous avez pas trop penser à faire le boulot du DBA, vous allez peut-être vous prendre des Table Scan en mémoire du "client" si vous faites pas trop gaffe.

Franchement pour des requêtes "en dur" type "réalise un classement des 3 plus grands scores par jours sur une plage de date", je mets ça dans une procédure stockée avec tous les détails d'implémentation dedans. S'il y a migration de la base, la procédure stockée sera dans le périmètre de la migration et mon application n'aura rien à faire pour si adapter. Après, soit l'ORM peut gérer ce type de "shortcut", soit c'est une petite rustine dans la DAL et ça se gère facilement.

Attention à ne pas trop dépendre de fonctionnalités très évoluées de votre ORM si vous voulez rester libre de changer d'ORM (=> nouvelle version de la DAL mais assez facile à faire car peu intégré à l'ORM "précédent"), sinon vous risquez de rester tanqué avec lui. Passer d'un ORM à un autre, avec le même niveau de fonctionnalité est assez simple (=> nouvelle version de la DAL).

Pour du CRUD, le niveau de fonctionnalité d'un ORM n'est pas un gros problème. 

Récemment on est passé de la version MySQL 5 à une version 8

La monté en version c'est plutôt bien passé

Après c'est vrais que si on aurait passé sur un autre SGBDR j'aurai peut-être moins rigolé   

Pour l'utilité des ORM,

Je le voit pour l'instant, surtout avec les exemples suivants :

(Changement du nom d'une colonne/table) 

(Amélioration de la structure (clés primaire sur le nom de la ligne) -> Créer un id_ligne et placer la clés primaire dessus) 

....  

==> Avec l'évolution du projet j'adorerai renommer certaines colonnes ou améliorer la structure, le problème c'est que je doit revenir sur l'ensemble des requêtes qui l'utilisent

Je vais commencer à me former sur un Entity Framework en essayant de créer la partie configuration, et sur les prérequis de la sécurité dans ASP.NET  . 

-
Edité par DeveloSt 31 mars 2021 à 11:29:01