Fornitore di app vs fornitore di plug-in - chi è responsabile della correzione?

-5

Un'app genera un PDF basato sui dati inseriti dall'utente nei campi di testo. Copia e incolla gli utenti possono inavvertitamente finire incollando "tag" nel campo. Ad esempio -

<[email protected]>  

Il plug-in del generatore PDF non piace e si arresta in modo anomalo generando un'eccezione. Il venditore di App dice che "l'escape deve essere eseguito sul lato del plugin" poiché tutti i loro strumenti / plugin sono simili - escape per sql injection, cross site ecc. Il fornitore di plug-in dice che il venditore di App deve sfuggire ai tag.

I miei pensieri iniziali sono che questo non è sufficiente per un errore catastrofico che il plug-in genera. Mi sarebbe piaciuto avere un PDF ancora generato ma con un messaggio "Qualcosa è andato storto, problema con ..." o semplicemente ignorare il tag sconosciuto e mostrarlo come è nel PDF (l'ho visto prima in un'app business ). Ma non sono sicuro da che parte cada questa bella gestione degli errori.

In termini di progettazione software, app vs plug-in, da che parte è responsabile oggettivamente in questo caso?

L'app prende i dati dal database (originariamente inserito dall'utente) e prepara una stringa HTML di base per la conversione, ad esempio in un'azione del controller dell'app:

$html = "<html>...<p>$userNotes</p>...</html>";
return Response($this->plugin->htmlToPDF($html));
    
posta user95437 26.10.2018 - 13:51
fonte

1 risposta

4

Alla fine questa è una questione contrattuale o interpersonale, non tecnica.

Tuttavia, potrebbero esserci alcune considerazioni tecniche. L'app di solito presenta una particolare interfaccia plugin. I fornitori di plug-in dovranno rispettare questa interfaccia. Se l'interfaccia documentata riguarda i dati senza escape, il fornitore del plug-in dovrà eseguire l'escape necessario.

In effetti, potrebbe essere impossibile disinfettare o scappare correttamente i dati prima di inviarli a un plug-in. Diversi formati hanno regole di escape diverse. Non esiste un formato che sia accettabile per tutti i plugin. Se ai plug-in fossero stati consegnati dati di escape, la maggior parte dei plug-in avrebbe dovuto prima sganciarli.

Come esempio di questa difficoltà, considera l'input dell'utente che contiene un carattere di virgoletta doppia " . Come dovrebbe essere evaso per diversi formati?

  • JSON, SQL 1 : backslash-escape: \"
  • XML, HTML: riferimento al carattere &34; o &quot; , a volte non è necessaria alcuna escape
  • alcuni dialetti CSV: ripetizione: ""
  • POSIX shell: backslash-escape \" o virgolette singole: '"'
  • La shell CMD:% caret% co_de, a volte non è necessaria alcuna escape

1 L'escaping manuale per SQL è solitamente inappropriato, in quanto le dichiarazioni preparate dovrebbero essere preferite.

Considerazioni simili non si applicano solo per "caratteri speciali", ma anche per codifiche di caratteri come UTF-8: la stessa codifica non sarà accettata da tutti i consumatori, quindi la codifica deve essere documentata e convertita in modo esplicito.

    
risposta data 26.10.2018 - 14:26
fonte

Leggi altre domande sui tag