Tattica per il recupero del contenuto reso lato server rispetto ai dati non elaborati

1

Attualmente sto sviluppando un'API (node / express js) per un sito web di blog che utilizza un parser markdown ( showdown ) per il rendering di contenuti e un disinfettante HTML ( html-santize ) per la rimozione di html / js dannosi.

Attualmente sono al punto in cui voglio consentire a un utente di modificare un post, ma non voglio esporre il contenuto "grezzo" ad altri utenti diversi dal creatore / proprietario del post del blog.

Preferibilmente vorrei utilizzare lo stesso percorso che utilizzo per recuperare dati grezzi ( GET /blog/:id?raw=true ) che è più difficile da proteggere perché fluiscono attraverso lo stesso controller, mentre raw=false sarebbe un percorso aperto e raw=true sarebbe essere un percorso sicuro Potrei quindi giocherellare con alcuni middleware e cose del genere, ma sembra tutto un po 'hacky e non penso che sia un buon progetto dell'API.

L'altra opzione che sto considerando è l'implementazione di un nuovo percorso ( GET /blog/raw/:id ), che sarebbe facile da proteggere, ma avrei 2 percorsi di andata per la stessa risorsa in forme diverse.

So che qui non c'è una risposta corretta, ma mi piacerebbe sentire le tue opinioni su questo.

    
posta Alexander 22.06.2017 - 18:13
fonte

1 risposta

1

Il solito design per una modifica è di avere GET /blog/:id/edit restituire una pagina HTML con la casella di testo riempita con la versione raw, che quindi POST /blog/:id/edit la aggiornerebbe. Quindi si protegge il percorso di modifica. Questo percorso viene generalmente utilizzato quando si lavora con un browser Web che naviga direttamente verso di esso.

Se disponi di un front-end non HTML (JavaScript, un'app), che ti dà il controllo completo di come parli con l'API Web, puoi invece utilizzare le intestazioni per chiedere un rendering diverso. Solitamente è meglio prendere in considerazione solo i dati nei parametri di query / postare i dati mentre le istruzioni su come eseguire il rendering (come la scelta della lingua, il formato) di solito vengono trasmesse meglio attraverso le intestazioni, quando si ha l'opzione.

Ad esempio, GET /blog/:id \ Accept: text/html (dove \ è una nuova riga) per ottenere la versione renderizzata e GET /blog/:id \ Accept: application/json per ottenere la versione non elaborata e continuare a utilizzare PUT /blog/:id . Se non vuoi o non puoi usare Accept (cioè, perché stai già restituendo JSON), sei libero di creare un'altra intestazione per comunicare con la tua applicazione, come X-Post-Format: html e X-Post-Format: raw 1 . A quel punto non avrei nemmeno protetto la versione raw, solo il POST / PUT, poiché la versione raw è solo un diverso formato della versione renderizzata. Basta disinfettare l'HTML prima di memorizzarlo.

Il modo in cui lo fai per la tua lingua specifica è una domanda per Stack Overflow.

1 Il prefisso X- è deprecato per gli standard di intestazione. È contrassegnato come "NON DEVE", il che significa che puoi ancora usarlo se vuoi.

    
risposta data 22.06.2017 - 20:07
fonte

Leggi altre domande sui tag