Perché i siti di archiviazione di file hanno un ID univoco lungo per i loro collegamenti di download?

Is there any (security) reason behind for having it that way?

Sì - un tipo di Sicurezza attraverso l'oscurità - i file non sono veramente sicuri poiché gli URL sono disponibili senza autenticazione , ma li renderebbe ragionevolmente privati in quanto non sono ipotizzabili. Avresti bisogno di più informazioni (come i log della cronologia del browser) o di qualche tipo di forza bruta che sarebbe inapplicabile in questo caso.

I was thinking maybe they do it like that so that people can't just increment the id by 1 and just download everything they come across which would result in unnecessarily losing of more bandwidth. But that is not the case, because both the ID and FILE NAME need to match, and file names aren't easily guessable.

Non sono loro? Che ne dici di readme.txt , password.txt , untitled.bmp , CV.doc , ecc.

elenchi di parole comuni sono ampiamente disponibili e possono essere alimentati in un programma di forza bruta in combinazione con estensioni di file comuni e ID diversi per eseguire un attacco sul tuo sistema. Questo è il motivo per cui è una buona idea avere un componente casuale sicuro nei tuoi URL.

Bene, più della sicurezza (che è possibile ottenere con altri mezzi, come l'autenticazione appropriata), il problema è che quando si hanno più front-end, non è possibile implementare facilmente un numero di serie, e scalare, esp. se il servizio è anche distribuito geograficamente (per il ripristino di emergenza o solo per problemi di posizione).

Immagina un servizio simile a Dropbox con migliaia di server di archiviazione, memorizzando i file, chi manterrà un indice di ciò che è il numero corrente del file? Anche all'interno dello stesso account, hai lo stesso problema con i client che caricano file contemporaneamente.

Il modo per evitare questo è quello di creare URI per i file in modo tale che la possibilità di collisioni sia trascurabile. Ecco perché sistemi come SQL server hanno sempre supportato sia un indice primario con incremento automatico, sia un ID univoco basato su GUID. Per le persone che hanno lavorato su database, abbiamo quasi sempre utilizzato i GUID a meno che non fossimo sicuri che avremmo sicuramente un singolo server DB, nel qual caso l'incremento automatico è stata la migliore esperienza possibile.

Usano gli URL come chiavi di accesso perché è molto più semplice da ridimensionare. Invece di cercare il file, quindi di contattare un database master per verificare se sei effettivamente autorizzato ad accedere al file in base a un altro segreto (un cookie di sessione, ad esempio), presuppongono che l'URL sia lungo e abbastanza casuale che se lo sai devi essere autorizzato ad accedervi, senza bisogno di interrogare un servizio di autenticazione separato.

Gli svantaggi sono che non è facile revocare l'accesso a un file, specialmente se sono memorizzati nella cache (dovresti attendere la scadenza delle cache) e gli URL possono perdere più facilmente dei cookie di password / sessione perché sono facilmente accessibili per esempio nella cronologia dell'utente e nei log dei proxy di intercettazione HTTPS dell'azienda.