Avantages et inconvénients de l'utilisation de DB id dans l'URL?

Question

Par exemple: http://stackoverflow.com/questions/396164/exposing-database-ids-security-risk et http://stackoverflow.com/questions/396164/ blah-blah charge la même question.

(Je suppose que ceci est l'ID de la table des questions de la base de données? S'agit-il d'une norme dans ASP.NET?)

Quels sont les avantages et les inconvénients de l'utilisation de ce type de système dans votre application Web?

Answer 1

Eh bien, d’une part, les identifiants simples sont généralement séquentiels, il est donc assez facile de deviner et de récupérer d’autres données à partir de votre application.

Charger du code JSON au moment de l'exécution plutôt que de manière dynamique via AJAX https://stackoverflow.com/questions/395858/doesnt-matter-what-I- tapez-ici

Maintenant, cela dit, cela pourrait aussi être considéré comme un bonus, car personne sensé ne voudrait que toute leur sécurité repose sur le fait que vous devez cliquer sur un lien pour accéder à vos données sécurisées , et par conséquent, la facilité de découverte des données pourrait être bonne.

Cependant, il est un moment où vous allez réindexer votre base de données. Avoir quelque chose qui rend l'ancienne URL invalide serait mauvais, si pour aucune autre raison les moteurs de recherche avaient toujours d'anciens liens.

De plus, ici, sur SO, il est tout à fait normal d’utiliser des liens comme celui-ci vers d’autres questions. Par conséquent, s’ils veulent à nouveau réindexer et ainsi renuméroter (ou passer aux guides), ils devront tout de même conserver l’ancienne structure et Les identifiants.

Maintenant, est-ce que cela va probablement arriver ou être nécessaire? Probablement non.

Je ne m'inquiéterais pas trop à ce sujet, construisez simplement votre sécurité comme si chaque point d'entrée de votre application était connu et qu'il ne devrait y avoir aucun problème.

Answer 2

1. L'ID de base de données est utilisé pour rechercher la question dans la base de données. C'est numérique ce qui signifie: rapide. Si vous le laissiez de côté, vous deviez rechercher le titre qui est beaucoup plus lent.

2. La question elle-même fait partie de l'URL pour la rendre "conviviale pour les moteurs de recherche". Ce sera mieux classé par g ** gle, etc.

Answer 3

Pro:

• Très facile à récupérer les informations de la page. Prenez l'ID, appelez la base de données, alto. Votre table sera (devrait) être indexée pour rendre cette recherche très rapide.
• URL unique garantie.

Con:

• Les identifiants de votre système sont affichés publiquement. Pas de problème dans un système accessible au public comme SO. Toutefois, des mesures de sécurité appropriées à l’arrière du serveur peuvent éviter que cela ne pose un problème, même sur des systèmes sensibles.
• Des URL laides. Les numéros à 6 chiffres ou plus sont difficiles à retenir et rendent plus difficile la distinction des pages, si ce nombre est tout ce qui l'identifie. Cela peut également avoir des conséquences sur le référencement, car les URL contenant des informations plus pertinentes et bien structurées sont généralement mieux classées. SO compense en fournissant également le nom du message dans l'URL. Bien que je ne puisse toujours pas annoncer un message particulier à mon ami lors du déjeuner, je le trouve toujours plus facilement dans l'historique du navigateur.
• Recherches plus lentes. Les recherches de texte dans une base de données sont généralement plus lentes.

Answer 4

Mais souvenez-vous que dans une communauté comme celle-ci, il y a une plus grande chance (bien que toujours minime) que le même nom de question soit affiché en même temps, ce qui aurait pour effet de casser des choses, de sorte qu'une identification unique doit être appliquée. Les identifiants sont probablement tout à fait logique dans le contexte dans lequel cette application Web particulière a été développée.

Answer 5

Je ne pense pas que ce soit une mauvaise pratique, et assez commune, de le faire dans ASP.NET et d'autres frameworks. Comme @lassevk l'a dit, si votre sécurité en dépend, vous avez besoin de vérifications supplémentaires (l'utilisateur X peut-il enregistrer Y), mais cela dépend davantage de la convivialité des URL pour les sites publics pour les sites de référencement.

Par exemple, les URL des SO sont plutôt conviviales:

  

Avantages et inconvénients de l'utilisation de l'ID de base de données dans le URL?

google note les informations au début de l'URL plus haut qu'à la fin, afin que cela ressemble à ceci:

  

https://stackoverflow.com/pros -et-a-contre-utilisation-de-db-id-dans-l'url / q / 407120

devrait obtenir un meilleur classement pour les "avantages et inconvénients de l'utilisation de db id dans l'URL" . Ce n'est pas le seul facteur, mais c'est un problème majeur. Regardez le format d'Amazon, ils le font pour une très bonne raison:

  

http://www.amazon.com/Maverick-Ricardo-Semler/dp / 0712678867

     

http: // serveur / nom du livre / dp / id du livre

Wordpress le fait comme ceci:

  

http: // serveur / aaaa / mm / jj / nom-de -le-post

Toutefois, si vous publiez le même jour deux publications intitulées "foo", vous obtenez:

  

http: // serveur / aaaa / mm / jj / foo

     

http: // serveur / aaaa / mm / jj / foo2

le slug (foo / foo2) n’est pas une PK, mais il est maintenu comme unique sur la table des posts.

Je pense que l'insertion de l'ID dans l'URL n'est pas un problème, à moins que votre URL ne soit un GUID! Bien trop long et difficile à taper. Si c'est un int ou une sorte de guide court (par exemple 6-8 caractères), alors ça ne devrait pas être un problème.