security - tablas - tipos de datos en access

Usar el campo de clave principal/ID como identificador en una URL

Question

¿Cuáles son los pros y los contras de utilizar la clave principal de su base de datos como un identificador de URL? Como ejemplo, http: // localhost / post / view / 13 - 13 es mi clave principal para mi tabla de publicaciones.

Algunos sitios como reddit usan lo que supongo es una identificación única que no es la clave principal, pero sigue siendo única para ayudar a identificar el enlace:

http://www.reddit.com/r/funny/comments/7ynin/the_mystery_of_irelands_worst_driver/

Puede cambiar la última parte de la URL a lo que desee, siempre que / 7ynin / sea el mismo.

Digg parece usar un slug del título de enlaces para identificar un enlace:

http://digg.com/space/Liquid_Water_Recently_Seen_on_Mars

Si bien recuerdo correctamente, una instalación de WordPress predeterminada usa index.php? P = # como su id hasta que se habiliten las url de fantasía.

Puedo ver por qué, por SEO, querría tener la url más informativa posible, pero solo estoy tratando de ver si el uso de la clave principal es un riesgo de seguridad o simplemente una mala forma.

Answer 1

Como dijiste, el objetivo de poner títulos directamente en la URL es SEO. Tener palabras clave en la URL tiene un efecto significativo en los resultados del motor de búsqueda.

Sin embargo, algunos otros pensamientos relacionados con sus ejemplos:

• No estoy seguro de por qué supone que la clave alfanumérica reddit no es la primaria, no hay nada que obligue a las claves primarias a ser numéricas. Si se trata de un identificador único para la publicación, no hay razón para no utilizarla como clave principal (o al menos como parte de ella).

• Digg realmente impone la singularidad de los títulos (quizás solo dentro de una categoría particular, hace años que no he estado en Digg, así que no puedo recordar). Solía ​​ver esto con bastante frecuencia con una historia duplicada que tiene una URL como:

  http://digg.com/space/Liquid_Water_Recently_Seen_on_Mars_2

  Esto implica que el título es al menos parte de la clave principal, ya que esa es la única forma de identificar a qué historia se pretendía apuntar el enlace.

En realidad, no existe ningún riesgo de seguridad significativo al usar la clave principal en la URL, aparte de la capacidad de las personas para adivinar / predecir otras, como se menciona en pantulis. Pero no debes confiar en que "nadie va a adivinar esto" como una medida de seguridad de todos modos.

Answer 2

No es intrínsecamente un riesgo para la seguridad, aunque le dice a las entidades externas cosas sobre su sistema, lo cual generalmente es una buena práctica para evitar.

Answer 3

Si no incluye la (s) clave (s) primaria (s) en la URL / enlace, entonces debe crear algún tipo de clave sintética temporal Y, luego, debe guardar la asignación de esa clave en la sesión para el usuario. Esto agrega más uso de estado / memoria / algo para romper con su aplicación.

Si el valor es realmente sensible, vale la pena el costo de ocultarlo. Sin embargo, oscurecer la clave realmente no lo hace seguro, ¿verdad? Debe verificar las funciones de usuario en cualquier "controlador" (servlet, código subyacente, lo que sea) antes de otorgar acceso al elemento.

Answer 4

Una estafa: cualquier visitante puede intentar adivinar fácilmente otras identificaciones, que pueden no ser las que usted desea.

Answer 5

Siempre desea presentar al usuario una buena URL, no una desagradable identidad autogenerada. Pero no creo que deba hacer que dicha "URL amigable" sea la clave principal. Debería seguir usando un PK numérico autoincrementado "clásico" y tener una segunda columna que sea una "URL amigable" única. ¿Por qué?

1. Todas las tablas de comentarios, tablas de calificaciones, las tablas que tengan una relación con su tabla de contenido pueden usar la clave principal numérica. Esto significa índices más pequeños y menor uso de memoria.
2. Alguien querrá cambiar la URL amigable. Si tiene una clave principal numérica, no tiene que actualizar ninguna de sus tablas dependientes (ni hacer que el DB lo haga a través de una actualización en cascada).
3. En el futuro, puede abstraer los bits de URL en otra tabla. Dicha tabla puede almacenar las asignaciones de URL "heredadas" que emiten redireccionamientos al mapa de URL principal "real". Luego, cuando el usuario quiera cambiar la URL amigable, no tiene que romper todas las URL heredadas entrantes. No se pudo hacer esto si su clave principal era la "URL amigable".
4. Todavía me inclinaría a utilizar la clave primaria numérica en todo mi AJAX goo (por ejemplo, una función javascript post_new_comment () tomaría la clave principal, no una URL amigable). La única vez que usaría la URL amigable es en cualquier estructura de URL de usuario.
5. En cuanto a la seguridad? Si su contenido es de acceso controlado, tendrá que verificar el acceso sin importar si es la clave principal o alguna URL amigable.
6. Si permite formas de acceder al contenido a través de la clave principal, las personas pueden intentar ingresar identificaciones aleatorias. Si su requisito no solo es el acceso limitado al contenido, sino la negación de dicho contenido, se trata de la redacción de sus errores. Es lo mismo que con los errores de inicio de sesión: no dice "nombre de usuario no encontrado", dice "nombre de usuario o contraseña incorrectos". Conectar los valores aleatorios para encontrar contenido va a ser un problema para cualquier enfoque que tome, es solo que con las teclas numéricas hay menos valores para probar.

En pocas palabras: ¿URL amigables? Demonios si. Utilizándolos como la clave principal? Diablos no

Answer 6

Reddit también usa ID numérico, pero se convierte utilizando Base 36 , por lo que aparece como una cadena. Es como el número hexadecimal, que de hecho también es una cadena. La única diferencia es la base.

Base 36 es "el sistema numérico alfanumérico más insensible a mayúsculas y minúsculas que utiliza caracteres ASCII" y es fácilmente codificable y decodificable. ¿Por 36? AZ = 26 + 0-9 = 10.