¿Pros y contras de usar DB id en la URL?

Question

Por ejemplo: http://stackoverflow.com/questions/396164/exposing-database-ids-security-risk y http://stackoverflow.com/questions/396164/ blah-blah carga la misma pregunta.

(¿Supongo que este es el ID de DB de la tabla de preguntas? ¿Es este estándar en ASP.NET?)

¿Cuáles son los pros y los contras de usar este tipo de esquema en su aplicación web?

Answer 1

Bueno, por un lado, los ID simples suelen ser secuenciales, por lo que es bastante fácil adivinar y recuperar otros datos de su aplicación.

Cargue JSON en tiempo de ejecución en lugar de dinámicamente a través de AJAX https://stackoverflow.com/questions/395858/doesnt-matter-what-I- escribe aquí

Ahora, habiendo dicho eso, eso también podría ser visto como un bono, porque nadie en su sano juicio haría que su seguridad dependa completamente del hecho de que tiene que hacer clic en un enlace para acceder a su datos seguros , y por lo tanto, el fácil descubrimiento de los datos podría ser bueno.

Sin embargo, un punto es que en algún momento vas a reindexar tu base de datos, tener algo que haga que la antigua URL sea inválida sería malo, si no fuera por otra razón que los motores de búsqueda aún tendrían enlaces antiguos.

Además, aquí en SO, es bastante normal usar enlaces como este para otras preguntas, por lo que si en algún momento desean reindexar y renumerar las cosas (o pasar a las guías), aún tendrán que mantener la estructura antigua y ID's.

Ahora, ¿es probable que esto suceda o sea necesario? Probablemente no.

No me preocuparía demasiado por eso, solo construya su seguridad como si se conociera cada punto de entrada a su aplicación y no debería haber problemas.

Answer 2

1. El ID de la base de datos se usa para buscar la pregunta en la base de datos. Es numérico lo que significa: rápido. Si lo dejabas fuera, tenías que buscar el título, que es mucho más lento.

2. La pregunta en sí misma es parte de la URL para que sea amigable para los motores de búsqueda " ;. Se clasificará mejor por g ** gle, etc.

Answer 3

Pro:

• Súper fácil de recuperar la información de la página. Toma la identificación, llama a la base de datos, viola. Su tabla será (debería) indexada para que esta búsqueda sea súper rápida.
• URL única garantizada.

Con:

• Las ID en su sistema se muestran públicamente. No es un problema en un sistema disponible públicamente como SO. Sin embargo, las medidas de seguridad adecuadas en el back-end pueden hacer que esto no sea un problema, incluso en sistemas sensibles.
• URLs feas. Los números de más de 6 dígitos son difíciles de recordar y hacen que sea más difícil distinguir las páginas, si el número es todo lo que lo identifica. Esto también puede tener consecuencias de SEO, ya que las URL con información más relevante y bien estructurada generalmente se clasifican mejor. SO compensa al proporcionar el nombre de la publicación en la URL también. Si bien todavía no puedo recitar una publicación en particular a mi amigo en el almuerzo, aún puedo encontrarla más fácil en el historial del navegador.
• Búsquedas más lentas. En general, hacer búsquedas de texto en una base de datos es más lento.

Answer 4

Pero recuerde que en una comunidad como esta existe una posibilidad más alta (aunque todavía mínima) de que el mismo nombre de pregunta se publique al mismo tiempo, lo que rompería las cosas, por lo que se debe aplicar algún tipo de identificación única, las identificaciones son probablemente bastante lógico en el contexto en el que se desarrolló esta aplicación web en particular.

Answer 5

No creo que sea una mala práctica, y bastante común, hacerlo en ASP.NET y otros marcos. Como dijo @lassevk, si su seguridad depende de ello, entonces necesita algunas comprobaciones más (el usuario X puede grabar en Y), pero se trata más de la facilidad de uso de las URL para los sitios públicos.

Por ejemplo, las URL de SO son bastante amigables:

  

Ventajas y desventajas de usar el ID de DB en el URL?

Google califica la información al INICIO de la URL más alta que al final, por lo que debe tener el siguiente aspecto:

  

https://stackoverflow.com/pros -y-contras-de-usar-db-id-in-the-url / q / 407120

debería obtener una clasificación más alta para " pros y contras de usar db id en la url " . No es el único factor, pero es bastante importante: mira el formato de Amazon, lo hacen por una muy buena razón:

  

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

     

http: // server / book-name / dp / book-id

Wordpress lo hace así:

  

http: // server / yyyy / mm / dd / name-of -el-post

sin embargo, si publicas dos publicaciones el mismo día llamadas " foo " ;, obtienes:

  

http: // server / aaaa / mm / dd / foo

     

http: // server / aaaa / mm / dd / foo2

la babosa (foo / foo2) no es una PK, pero se mantiene como única en la tabla de publicaciones.

Creo que poner la ID en la URL no es un problema, ¡a menos que su URL sea un GUID! Demasiado tiempo, y difícil de escribir. Si es un int, o algún tipo de guía breve (por ejemplo, 6-8 caracteres), entonces no debería ser un problema.