Codifica difensiva contro una specifica del servizio WSDL "ufficiale"

Question

Codifica difensiva contro una specifica del servizio WSDL "ufficiale"

#1 da (1 voti)
#2 da (1 voti)
#3 da (-1 voti)

0

Oggi mi è stato chiesto di diagnosticare un problema in qualche codice di sviluppo. Si è scoperto che il problema era causato da una nuova implementazione stub che restituiva dati casuali che non corrispondevano alle specifiche del servizio.

Ciò ha portato a una conversazione con altri per quanto riguarda l'approccio corretto per affrontare questo scenario e una serie di punti di vista diversi e sono curioso di sapere cosa direbbero gli altri.

I documenti delle specifiche del servizio affermano che per questo campo non restituiremo nulla, 'A' o 'D'. (Optional / string (1))

Lo stub era stato configurato a quel punto per restituire un valore di '8whMJiAIIg', che corrispondeva alla definizione WSDL (stringa).

Usiamo un modello che espone un oggetto di risposta (wcf / .NET) che viene popolato dalla risposta del servizio / stub (tradotto di conseguenza) e l'implementazione di questo è stata scritta secondo le specifiche del servizio e stava verificando la esistenza di A o D o non restituire nulla.

In definitiva, poiché il valore non era A o D che doveva essere in questo scenario, il codice non restituiva alcuni dati aggiuntivi e causava un'eccezione più avanti nel flusso.

La conversazione è passata alla codifica difensiva ed è qui che siamo divisi.

Quindi la mia domanda è questa;

Dovremmo fare affidamento sull'implementazione / stub del servizio per restituire i dati secondo le specifiche (questo è considerato un servizio interno, attendibile) o dovremmo sempre inserire il codice per confermare che i dati inviati sono effettivamente come per il servizio spec.

validation defensive-programming web-services

posta ChrisBint 07.07.2016 - 12:27

fonte

3 risposte

Leggi altre domande sui tag validation defensive-programming web-services

Posso parallelizzare facilmente questo script? Modifica di un documento master e non sovrascrivere tutto nelle singole "versioni"?

score 1 · Answer 1

Se hai uno schema che definisce cos'è un messaggio valido, il tuo software dovrebbe essere in grado di accettare tutto ciò che è valido dal punto di vista dello schema, anche se non ha senso nel contesto della tua applicazione. Una delle prime cose che fai quando ricevi un messaggio è di convalidare la sua correttezza.

Se sono presenti ulteriori restrizioni sul contenuto dello schema che non vengono catturate nello schema, provare a inserirle nello schema. A volte, potrebbe non essere possibile, come lo schema condiviso con un'ampia varietà di applicazioni con regole interne diverse. In questo caso, le applicazioni devono aggiungere la propria convalida dei messaggi ricevuti e fallire rapidamente se viene ricevuto un messaggio non valido.

In breve - dovresti sempre controllare. Dovresti anche spostare qualunque controllo tu possa fare la definizione del messaggio in modo che diventi difficile per chiunque usi la definizione del tuo messaggio di inviare un messaggio errato e facile per le applicazioni di convalidare il contenuto del messaggio.

score 1 · Answer 2

Se è interno, la convalida non è necessaria. Se è esterno, è necessaria la convalida.

Tuttavia; "interno" indica all'interno dello stesso pezzo di codice; dove se un pezzo viene sostituito, ti aspetti che l'intero oggetto (tutto interno) venga sostituito nello stesso tempo.

Poiché "la parte A comunica con la parte B tramite qualsiasi oggetto che coinvolge socket", è esterna. In quel caso non si tratta di stabilire se è necessaria la convalida; è una questione di se hai bisogno di autenticazione e crittografia (ad esempio per difendersi dagli attacchi "man in the middle") oltre alla convalida.

score -1 · Answer 3

Per un servizio interno e affidabile, farei affidamento sulle specifiche, supponendo che tu abbia modo di captarlo rapidamente se succede, con l'aiuto dei test unitari.

Se si tratta di un servizio esterno che potrebbe essere utilizzato da una terza parte, è necessario aggiungere la convalida per confermare che i dati inviati si basano sulle specifiche.