Pro e contro dell'utilizzo dell'ID DB nell'URL?

Question

Ad esempio: http://stackoverflow.com/questions/396164/exposing-database-ids-security-risk e http://stackoverflow.com/questions/396164/ blah-blah carica la stessa domanda.

(Immagino che questo sia l'ID DB della tabella Domande? È lo standard in ASP.NET?)

Quali sono i pro e i contro dell'utilizzo di questo tipo di schema nella tua app web?

Answer 1

Bene, per esempio, i semplici ID sono solitamente sequenziali, quindi è abbastanza facile indovinare e recuperare altri dati dalla tua applicazione.

Carica JSON in fase di esecuzione anziché in modo dinamico tramite AJAX https://stackoverflow.com/questions/395858/doesnt-matter-what-I- tipo-qui

Ora, detto questo, ciò potrebbe anche essere visto come un bonus, perché nessuno nella loro mente giusta farebbe tutta la loro cerniera di sicurezza sul fatto che devi fare tintinnio su un link per accedere ai tuoi dati sicuri , e quindi una facile reperibilità dei dati potrebbe essere buona.

Tuttavia, un punto è che a un certo punto hai intenzione di reindicizzare il tuo database, avere qualcosa che rende invalido il vecchio url sarebbe male, se per nessun altro motivo che i motori di ricerca avessero ancora vecchi collegamenti.

Inoltre, qui su SO è abbastanza normale usare collegamenti come questo per altre domande, quindi se ad un certo punto vogliono reindicizzare e rinumerare le cose (o passare a guid), dovranno comunque mantenere la vecchia struttura e id.

Ora, è probabile che accada o sia mai necessario? Probabilmente no.

Non me ne preoccuperei troppo, costruisci la tua sicurezza come se ogni punto di accesso alla tua applicazione fosse noto e non dovessero esserci problemi.

Answer 2

1. L'ID del database viene utilizzato per cercare la domanda nel database. È numerico che significa: veloce. Se vuoi lasciarlo fuori, devi cercare il titolo che è molto più lento.

2. La domanda stessa fa parte dell'URL per renderla "amichevole ai motori di ricerca". Sarà classificato più in alto di g ** gle ecc.

Answer 3

Pro:

• Super facile da recuperare le informazioni sulla pagina. Prendi l'ID, chiama il database, viola. Il tuo tavolo verrà (dovrebbe) indicizzato per rendere questa ricerca super veloce.
• URL unico garantito.

Con:

• Gli ID nel tuo sistema vengono visualizzati pubblicamente. Non è un problema in un sistema pubblicamente disponibile come SO. Tuttavia, adeguate misure di sicurezza sul back-end possono rendere questo non un problema anche su sistemi sensibili.
• URL brutti. I numeri con più di 6 cifre sono difficili da ricordare e rendono più difficile distinguere le pagine, se il numero è tutto ciò che lo identifica. Ciò può anche avere conseguenze SEO, in quanto gli URL con informazioni più pertinenti e ben strutturate sono generalmente classificati meglio. SO compensa fornendo anche il nome del post nell'URL. Anche se non riesco ancora a scuotere un particolare post dal mio amico a pranzo, posso ancora trovarlo più facilmente nella cronologia del browser.
• Ricerche più lente. Effettuare ricerche di testo su un database è generalmente più lento.

Answer 4

Ma ricorda che in una comunità come questa c'è una maggiore (anche se minima) possibilità che lo stesso nome di domanda venga pubblicato contemporaneamente, il che spezzerebbe le cose, quindi è necessario applicare un tipo di identificazione univoca, gli ID sono probabilmente abbastanza logico nel contesto in cui è stata sviluppata questa particolare applicazione web.

Answer 5

Non penso che sia una cattiva pratica, e abbastanza comune, farlo in ASP.NET e altri framework. Come ha detto @lassevk, se la tua sicurezza dipende da questo, allora hai bisogno di alcuni controlli in più (può l'utente X arrivare a registrare Y), ma tutto dipende dalla SEO-friendly degli URL per i siti pubblici.

Ad esempio, gli URL di SO sono abbastanza amichevoli:

  

Pro e contro dell'utilizzo dell'ID DB nel URL?

google valuta le informazioni all'inizio dell'URL più in alto rispetto alla fine, in modo che assomiglino a:

  

https://stackoverflow.com/pros -e-cons-di-uso-db-id-in-the-url / Q / 407120

dovrebbe ottenere un ranking più elevato per "vantaggi e svantaggi dell'utilizzo dell'id db nell'URL" . Non è l'unico fattore, ma è piuttosto importante: guarda il formato di Amazon, lo fanno per un'ottima ragione:

  

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

     

http: // server / nome-libro / dp / ID-libro

Wordpress lo fa in questo modo:

  

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

tuttavia, se pubblichi due post nello stesso giorno chiamato " foo " ;, otterrai:

  

http: // server / yyyy / mm / dd / foo

     

http: // server / yyyy / mm / dd / foo2

lo slug (foo / foo2) non è un PK, ma è mantenuto come unico sulla tabella dei post.

Penso che inserire l'ID nell'URL non sia un problema, a meno che il tuo URL non sia un GUID! Troppo lungo e difficile da scrivere. Se è un int o una sorta di guida breve (ad esempio 6-8 caratteri), allora non dovrebbe essere un problema.