2012-04-02 8 views
5

Sto creando un sito di condivisione video in django.Come directory sicure? E come creare nuove directory quando un utente si registra?

Attualmente, se un utente si registra e carica un video, verrà caricato su media/vid/uploaded-vid. Poi ho convertito usando ffmpeg in flv. Quello che vorrei fare è questo:

Qualcuno con il nome utente di alex1 registri, vorrei creare una directory per lui quando conferma la sua e-mail, chiamato /media/vid/members-vid/alex1

Se lui ha caricato un video, sarà convertito in flv in media/vid/uploaded-vid quindi copiato in /media/vid/members-vid/alex1. E il video in media/vid/uploaded-vid dovrebbe essere cancellato.

E vorrei mettere in sicurezza /media/vid/. Come si proteggono le directory di django? O è solo un apache chmod?

mi chiedevo se posso usare il sedano/rabbitqm per copiare i file da una cartella all'altra, o per creare nuove cartelle ..

+0

Sicuro da cosa? – mikerobi

+0

@mikerobi dagli hacker, voglio sapere qual è il modo più sicuro per archiviare i video sul mio server – user

+0

Intendevo, stai cercando di proteggere qualcuno dall'accesso a un video privato sul web, o se qualcuno accede al tuo server ? – mikerobi

risposta

3

L'utilizzo di una directory partecipazione sembra essere un buon compromesso. Tuttavia avere directory che prendono il nome dagli utenti è rischioso (e se qualcuno fornisce un nome che è un nome di comando eseguibile?), Quindi usare l'id utente potrebbe essere migliore. In effetti, se si hanno molti utenti, si potrebbe prendere in considerazione la possibilità di suddividere le directory utente in alcune directory generali per facilitare la ricerca delle directory per gli amministratori e perché alcuni file system hanno limiti piuttosto bassi sul numero di voci in una directory -- per esempio ext3 consente circa 32K voci.

Ad esempio, uno schema di directory utente grezzo con directory esterne denominate da 1 a 9 per le sottodirectory che iniziano con quei numeri vi darà un po 'più di flessibilità qui.

Quindi, a patto di avere i tuoi file caricati in /tmp/upload/1015/, e si desidera spostarli /var/userdata/01/1015/ ed elaborare i file in /var/userdata/01/1015/, di seguito potrebbe essere un approccio ragionevole:

  • /tmp/upload/1015/ dovrà essere utente apache o gruppo scrivibile
  • registrare la necessità di elaborare i file in /tmp/upload/1015/ in una banca dati, servizio di pianificazione AMQP come RabbitMQ o un RPC/servizi web chiamano
  • un client di servizio di pianificazione in esecuzione con il proprio userid raccoglie t ha lavoro da db/AMQP chiamata/web e non il seguente
    • eseguire un controllo virus
    • esegue un controllo di file di sanità mentale per vedere se il file di origine è quello che si aspetta
    • copia il file nella cartella utente
    • in caso di successo, rimuove il file originale (o pianifica un lavoro per farlo se non ha il permesso di farlo, o si affida a un cronjob per eliminare i file in /tmp/upload che hanno più di 24 ore)
    • tentativi di converti i file, aggiornando i flag di successo/fallimento rilevanti nel database mentre va avanti
    • elimina i file temporanei/fonte infruttuoso/file di output al termine

L'elenco, ovviamente, sarebbe andato avanti per un po 'più lontano, a seconda delle esigenze. Alla fine avremo una directory utente con file leggibili da apache ma non scrivibili dall'utente apache. Se il servizio cresce, puoi spostare i componenti di elaborazione video di questo servizio su un altro server.

A proposito c'è una descrizione molto buona di come fare questo genere di cose (molto semplicemente) da Cal Henderson di Flickr nel suo libro O'Reilly "Building Scalable Web Sites". È stato scritto nel 2006 ma il suo approccio è piacevolmente diretto e diretto.

+0

+1. Questa è una buona risposta. Un altro consiglio però: la fase di conversione dei file sta diventando la parte dell'elaborazione che esegue la maggior parte del codice, e questo codice sarà anche codice di terze parti complesso (codec e così via).Il codice preciso che viene eseguito sarà sotto il controllo dell'utente finale (dal momento che sceglie il tipo di file) e quindi questo codice dovrebbe essere tra le ultime parti privilegiate del codice. Certamente, non lasciarlo eseguire con privilegi per leggere il database, per non parlare di scriverlo. –

5

Per evitare che qualcuno caricamento di una conchiglia o qualche altro codice dannoso non si dovrebbe dare accesso caricare il file sui client esterni. Quindi, l'utente carica un file, che sedano ottiene quel file e lo elabora, mettendo il risultato in un altro percorso accessibile dal web server. Se l'elaborazione fallisce (ad esempio, il file non è un video valido), quindi nessuno può accedervi. Ma con la corretta configurazione del webserver (ad esempio, negare l'esecuzione di script da posizioni disponibili per il caricamento) non dovrebbe comunque essere un grosso problema.

Per evitare che gli utenti vedano i file privati ​​degli altri, è possibile anche collocare i file all'esterno dei file multimediali del sito e utilizzare le viste di django per controllare i diritti di accesso + speciale direttiva webserver per effettivamente serverare il file senza eseguire il proxy tramite Django. Queste direttive sono diversi per i server diffeent:

+1

Si consiglia di utilizzare il modulo [django-sendfile] (https://github.com/johnsensible/django-sendfile) per utilizzare le funzionalità di proxy del file. –

1

Potrebbe essere necessario memorizzare i video in mongoDB GridFS o qualcosa di simile. Quindi non avrai problemi con le directory, i file di archiviazione, i file eseguibili ...

Problemi correlati