sicurezza in selfhost web api

0

Attualmente sto delineando un progetto che sto svolgendo nel mio lavoro, dove avrò una WebAPI self hosted, connessa a un dispositivo seriale, dove l'app che sto creando configurerà quel dispositivo. No, non è un Raspberry PI:)

Quindi, invece di avere un database come origine dati per l'API, lo farei chiama al dispositivo seriale. Penso che sia un'idea carina e che posso usare la solita metodologia per lo sviluppo di API.

Quindi, ho una o due domande con cui potrei servirci.

Domanda 1: La mia azienda ha una quantità limitata di questi dispositivi seriali a scopo di test, quindi non posso fare affidamento sull'avere un dispositivo ogni volta che voglio testare il mio codice appena scritto. Quindi è una buona idea avere un flag nella richiesta http che specifica se l'API dovrebbe ottenere i dati dal dispositivo seriale o ottenere dei test da un documento? Stavo pensando a un middleware OWin in grado di indirizzare la chiamata al servizio corretto.

Domanda 2: sicurezza. Poiché l'API selfhost verrà installata sul computer locale degli utenti e la webapp chiamerà solo localhost, è necessario pensare alla sicurezza e all'autenticazione e simili? La websuite presente nella mia azienda ha già una soluzione di autenticazione, quindi è sufficiente? Ho sempre difficoltà quando si tratta di problemi di sicurezza, quindi non ho fiducia nelle mie capacità di ragionamento su questo argomento:)

    
posta Ingemar Skelander 06.10.2016 - 15:00
fonte

1 risposta

1

So instead of having a database as a data source for the API, I would make calls to the serial device

Suppongo che tu abbia già risolto l'accesso ai dati del dispositivo. Probabilmente, hai astratto l'accesso con un componente simile a DAO.

Il primo approccio sarebbe per prendere in giro il DAO . Mentre il componente principale ha accesso reale al dispositivo, il mocked fornisce dati da un documento (o da qualsiasi altro supporto).

Sarebbe interessante sapere se il DAO può recuperare lo stato del dispositivo (collegato / scollegato). Mentre il vero DAO potrebbe rispondere sì / no, il mock potrebbe rispondere sempre sì (o rendere la risposta parametrizzabile dalla configurazione).

Infine, fai in modo che funzionino del tutto implementando un gateway .

So is it a good idea to have a flag in the http-request that specifies whether the api should get the data from the serial device or get testdata from say a document?

Seguendo questo approccio, ti suggerisco di mantenere l'API più agevole possibile per l'ambiente. Tratta il dispositivo come se fosse un servizio esterno.

L'aggiunta di flag alla richiesta può frammentare il codice. Che cosa ti porterà a dichiarazioni if / else non funzionali e a perfezionare il modello con attributi privi di significato.

Utilizza invece Intestazioni HTTP . Implementa le intestazioni personali (seguendo alcuni locali ). Ecco una domanda correlata all'argomento.

Esempio:

GET: /my/resource/id
Headers: [X-Serial-Device: xxxx, ...]

GET: /my/resource/id
Headers: [...] # No device

Dato che WebAPI è auto-ospitato e fa principalmente richieste locali, non devi preoccuparti di alcun proxy che filtra le intestazioni.

L'intestazione potrebbe anche essere l'input necessario per cambiare DAO.

and the webapp would only call localhost, is there any need to think about security and authentication and the like?

Difficile dire con così pochi dettagli su a cosa serve la tua app. La sicurezza non è correlata a dove la mia app viene eseguita è più correlata a a chi avrà accesso? E cosa potranno fare? .

    
risposta data 08.10.2016 - 18:47
fonte

Leggi altre domande sui tag