Dovresti programmare per proteggere la tua applicazione da programmatori sbagliati?

Question

Non c'è dubbio che dovremmo codificare le nostre applicazioni per proteggersi da utenti malintenzionati, curiosi e/o incuranti, ma che dire dei colleghi attuali e/o futuri?

Ad esempio, sto scrivendo un'API basata sul Web che accetta parametri dall'utente. Alcuni di questi parametri possono essere associati a valori in un file di configurazione. Se l'utente crea problemi con l'URL e fornisce un valore non valido per il parametro, la mia applicazione effettuerebbe un errore quando provava a leggere da quella sezione del file di configurazione che non esiste. Quindi, naturalmente, scrub i parametri prima di provare a leggere dal file di configurazione.

Ora, se in fondo alla strada, un altro sviluppatore lavora su questa applicazione, aggiunge un altro valore valido per questo parametro che passerebbe il processo di lavaggio, ma non aggiunge la sezione corrispondente al file di configurazione. Ricorda, sto solo proteggendo l'app da cattivi utenti, non da programmatori malvagi. La mia richiesta fallirebbe.

Da un lato, so che tutti i cambiamenti dovrebbero essere testati prima di passare alla produzione e qualcosa del genere sarebbe senza dubbio in una sessione di test decente, ma d'altra parte, provo a costruire le mie applicazioni per resistere al fallimento come il migliore possibile Semplicemente non so se è "giusto" includere la modifica del mio codice da parte dei colleghi nell'elenco dei potenziali punti di errore.

Per questo progetto, ho deciso di non verificare se esistesse la sezione pertinente del file di configurazione. Come sviluppatore corrente, non consentirei all'utente di specificare un valore di parametro che causerebbe un errore, quindi mi aspetterei che un futuro sviluppatore non introduca un comportamento in un ambiente di produzione che potrebbe causare un errore ... o almeno eliminare tale caso durante il test.

Cosa ne pensi?

Pigro ... o filosoficamente valido?

Answer 1

"Semplicemente non so se è" giusto "includere la modifica del mio codice da parte dei colleghi nell'elenco di potenziali punti di errore".

Non è giusto impedire ai colleghi di rompere le cose.

Non sai a quali nuovi scopi verrà assegnato il tuo software. Non sai come sarà modificato in futuro.

Invece, fai questo.

Scrivere semplice software corretto, metterlo in produzione e smettere di preoccuparsi che qualcuno "rompa" qualcosa.

Se il software in realtà è semplice, altre persone possono mantenerlo senza romperlo.

Se lo rendi troppo complesso, lo interromperà (a) comunque, nonostante tutto quello che fai e (b) ti odiano per renderlo complesso.

Quindi, rendere il più semplice possibile per fare il lavoro.

Answer 2

Penso che sia responsabilità del futuro sviluppatore assicurarsi che non introduca bug o punti di errore nel codice. Quando esci dal progetto (se mai ?!), quindi parte del processo di firma dovrebbe essere almeno che il codice è stato presentato come privo di bug possibile, questo limiterebbe quindi la responsabilità che si detiene per problemi futuri.

Se il codice è conservato in un sistema di controllo di versione, sarebbe banale per te creare un tag che segnerebbe il punto in cui hai consegnato il codice, consentendo così di confrontare la base di codice corrente con il tuo originale sorge un bug che qualcuno sta cercando di incolpare su di te (se questo è l'angolo dal quale stai venendo!), quindi ti permette di dimostrare che sono le modifiche apportate all'implementazione originale che ha causato questi bug . (Presumendo ovviamente che le implementazioni causino comportamenti imprevisti e non correggano il codice "senza bug" grin).

Un metodo che ho usato in passato per garantire l'integrità dei dati (e non è infallibile), è controllare un input a offset specifici per valori specifici, assicurando che l'input non sia stato contaminato.

Spero che questo aiuti.

Answer 3

Sembra che tu stia prendendo misure ragionevoli per proteggersi dall'incompetenza facendo qualche scrubbing dell'input. Non credo che tu sia responsabile della protezione da qualsiasi possibile uso improprio del tuo codice o dell'input errato. Andrei oltre e dire che finché il tuo codice esplicitamente documenta ciò che è e non è un input accettabile, allora hai fatto abbastanza, specialmente se il codice di "errore di controllo idiota" aggiunto è gonfiato o (specialmente) più lento .

Una procedura che documenta esattamente quali input sono accettabili è ragionevole per una API interna. Detto questo, spesso codifico (sopra) in modo difensivo, ma ciò è dovuto principalmente all'ambiente in cui mi trovo e al mio livello di fiducia nel resto del codice.

Answer 4

Entrambi i modi vanno bene, filosoficamente parlando. Vorrei esprimere il giudizio basandomi sulla probabilità che tu pensi che ciò accada. Se puoi essere quasi sicuro che qualcuno possa infrangere il tuo codice in questo modo, potrebbe essere educato per te fornire un assegno che lo coglierà quando succederà.

Se non sembra particolarmente probabile, quindi è solo una parte del loro lavoro per assicurarsi che non infrangere il codice.

In entrambi i casi, tuttavia, le note tecniche (o altra documentazione appropriata) dovrebbero indicare chiaramente che quando viene apportata una modifica, è necessaria anche l'altra modifica.

Answer 5

Vorrei usare un commento in linea per gli sviluppatori futuri, o per uno sviluppatore come me che tende a dimenticare cosa stava succedendo in ogni parte dell'applicazione dopo che non ci ho lavorato per mesi.

Non preoccuparti di codificare effettivamente per sventare codificatori futuri, è impossibile. Basta aggiungere tutte le informazioni necessarie a qualcuno per supportare o estendere ciò che stai facendo nel contesto del codice sorgente.

Questa è la documentazione, come ha detto Steve B.. Mi accerterò solo che non sia esterno, perché ha la tendenza a perdersi.

Answer 6

Pigro ... o filosoficamente valido?

Pigro ... e arrogante. Codificando in un modo che fa apparire rapidamente gli errori, proteggi l'app contro i tuoi stessi errori, così come contro gli errori degli altri. Ognuno fa più errori di quanti pensano.

Ovviamente, anziché aggiungere altro codice per rilevare se il file di configurazione e il controllo dei parametri corrispondono, sarebbe molto meglio se il controllo dei parametri fosse basato sul file di configurazione in modo che ci fosse un solo posto dove sono aggiunti nuovi valori e un'incoerenza non è possibile.