asp consommant un service web, que faire de l'objet recordset ?

Question

Actuellement, j'utilise une page web ASP classique (ancienne) avec un objet recordset utilisé directement dans la mauvaise vieille méthode de code spagethi.

J'envisage de mettre en œuvre une couche de données en asp.net en tant que service web pour améliorer la gestion. C'est aussi un premier pas vers la mise à niveau du site web en asp.net. Le site lui-même reste ASP pour le moment...

Quelqu'un peut-il me recommander un bon moyen de remplacer le type d'objet recordset par un type compatible avec les services Web (comme un tableau ou autre) ? Que dois-je remplacer ci-dessous par.. :

set objRS = oConn.execute(SQL)
while not objRS.eof
   ...
   name = Cstr(objRS(1))
   ...
wend

et aussi que plusieurs jeux d'enregistrements peuvent être remplacés par ? Je parle de :

 set objRS = objRs.nextRecordset

Quelqu'un est passé par là et peut vous recommander ?

@AdditionalInfo - vous l'avez demandé :-)

Laissez-moi commencer par le début. La situation actuelle est : J'ai un vieux site web ASP avec un contenu hiérarchique classique (en-tête, section, sous-section, contenu) extrait de la base de données via des procédures stockées et les pages de contenu sont également dans la base de données (un lien vers le fichier html).

Le problème, c'est que le code ASP est réparti sur de nombreux fichiers .asp, qui établissent tous leurs propres connexions à la base de données, lisent et écrivent (il faut s'enregistrer pour le contenu). Récemment, nous avons eu des problèmes d'attaques par injection SQL et j'ai été appelé pour les résoudre.

I podría aller changer toutes les pages .asp pour empêcher l'injection sql mais ce serait de la folie. J'ai donc pensé construire une couche de données - toutes les pages utilisant cette couche pour accéder à la base de données. Un seul endroit pour corriger et mettre à jour le code d'accès à la base de données.

En prenant cette décision, j'ai pensé que la mise à jour d'asp.net n'était pas loin, pourquoi ne pas commencer à utiliser asp.net pour la couche de données ? De cette façon, il peut être réutilisé lors de la mise à niveau du site.

Ce qui m'amène aux questions ci-dessus !

Answer 1

L'injection SQL doit être gérée en utilisant des requêtes SQL paramétrées. Non seulement cela éliminera le risque de sécurité, mais cela accélérera considérablement les performances de votre base de données, car elle sera en mesure de réutiliser un plan d'exécution au lieu de le recalculer à chaque fois. La suggestion de gérer cela par des remplacements de chaînes de caractères est stupide. VB ne sait pas gérer les chaînes de caractères et ces instructions de "remplacement" seront extrêmement coûteuses en termes de performances et de mémoire (de plus, vous n'avez besoin de gérer que le caractère ' de toute façon).

Déplacer du code vers .net ne le rend pas meilleur. Avoir du code DB dans vos pages n'est pas mauvais, surtout si vous parlez d'un petit site avec seulement quelques développeurs. Des milliers de sites utilisent cette technique pour traiter des milliards de dollars de transactions. Maintenant, le sql dynamique non paramétré est mauvais et vous devriez travailler pour l'éliminer, mais cela ne nécessite pas une réécriture de l'application ou de .net pour le faire. Je suis toujours curieux de savoir pourquoi les gens considèrent .net comme une amélioration de facto de leur application. La plupart du mauvais code et des mauvaises habitudes qui existaient dans le modèle COM se propagent simplement lors d'une conversion.

Vous devez soit vous engager à créer une conception OO véritablement cohérente et à couplage minimal, soit conserver ce que vous avez, car ce n'est pas si mal.

Answer 2

Dommage que je n'aie pas vu cette question en 2008. Pour moi, il semble que votre site utilise le framework Justa. Un moyen simple est de modifier le code Justa pour soumettre la recherche et les entrées de données à urlencode. Je l'ai fait et cela fonctionne parfaitement pour moi.

Le reste du code est suffisamment sécurisé pour empêcher tout type d'injection SQL ou toute autre tentative d'accès à la base de données.