In che modo le applicazioni desktop comunicavano con il server remoto prima dei servizi Web?

11

Non ho molta esperienza con le applicazioni desktop, ma se dovessi creare un'app desktop del server client, l'accesso ai dati verrebbe effettuato tramite un servizio web. Credo che l'accesso ai dati tramite un servizio web offra sicurezza - Non ho bisogno di inserire il nome utente e la password del server db, ecc.

Prima dei servizi Web, come hanno fatto le applicazioni di database? Tutte le informazioni importanti sul db sono state trasferite nell'installazione dell'applicazione desktop? In tal caso, in che modo i programmatori hanno gestito l'aspetto della sicurezza? O i programmatori hanno usato qualcosa di simile ai servizi web?

programming-practices security

— Howls Hagrid
fonte

5

Ci sono state cose divertenti per le chiamate di procedure remote, come DCOM (Distributed COM), CORBA, Java RMI ... Non ne ho mai comprese completamente nessuna, mentre chiedere alcuni dati via HTTP ha immediatamente senso. Immagino che l'uso dei browser Web di tutti i giorni abbia reso i servizi Web più facili da individuare :-)

— marcus

3

@marcus: probabilmente perché HTTP ha incorporato la richiesta-risposta, mentre "alcuni protocolli su un socket" portano tutti a inventare quella ruota con una forma leggermente diversa.

— Steve Jessop,

11

A seconda di ciò che si chiama un servizio Web.

Prima di WSDL e REST, c'era ancora HTTP, quindi praticamente tutto quello che puoi fare ora potrebbe essere fatto anche prima.

C'è stata una mancanza di uniformità (motivo per cui WSDL e REST sono stati creati in primo luogo), ma ha fornito lo stesso livello di riservatezza e sicurezza dei dati di cui stai parlando.

In realtà puoi evitare di usare anche HTTP: puoi redigere il tuo protocollo e utilizzare un server personalizzato e client personalizzati che aprirebbero un socket a questo server e otterrebbero i dati di cui hanno bisogno (o pubblicano i dati). Qui, perdi tutti i vantaggi della standardizzazione di HTTP, ma ancora una volta non dai accesso ai database ai client.

— Arseni Mourzenko
fonte

17

Ah, quando avevamo bastoni e pietre.

Prima di Internet, avevamo qualcosa chiamato architettura "client / server" e reti locali. Se non stavi cercando di stabilire una connessione con un server a diverse miglia di distanza, queste reti funzionavano perfettamente per realizzare quasi tutto. È anche possibile stabilire lettere di unità e utilizzare connessioni a file server come un disco rigido remoto, se lo si desidera. Se ti trovassi a diverse miglia di distanza, potresti utilizzare una Wide Area Network per fare essenzialmente la stessa cosa, anche se a una velocità inferiore e a spese maggiori.

Il modo economico per parlare a distanza era passare informazioni attraverso le linee telefoniche usando dispositivi chiamati modem, e se volevi sistemare qualcosa in cui due computer si scambiavano conversazioni attraverso applicazioni informatiche, lo facevi nello stesso modo in cui lo fai oggi: stabilendo un protocollo di comunicazione. Non c'è nulla di magico in tutto ciò; entrambe le parti devono solo concordare sul significato di tutti i byte.

Sin dalle primissime fasi di Internet, esistevano modi in cui le macchine potevano comunicare attraverso di essa. I servizi Web sono solo l'ultimo gusto della settimana.

— Robert Harvey
fonte

5

"Non c'è nulla di magico in tutto su questo; entrambe le parti hanno solo essere d'accordo su ciò che tutti i byte media." E endianness :)

— HJK

2

@hjk, è facile: little-endian è evidentemente superiore a tutte le altre opzioni :-)

— Mark

3

Andrei persino al punto di dire che la definizione di Internet richiede che ci siano modi per comunicare attraverso le macchine. Se non riescono a farlo, non è Internet, è un mucchio di cavi con delusioni di grandezza.

— Steve Jessop,

2

@SteveJessop: Ti sbagli, " È una serie di tubi ".

— Deduplicatore

3

Solo per chiarire alcuni concetti prima ...

Credo che l'accesso ai dati tramite un servizio web offra sicurezza - Non ho bisogno di inserire il nome utente e la password del server db, ecc.

Penso che tu stia fondendo i concetti di (1) Transport Layer Security (TLS) e (2) controlli di accesso nella precedente dichiarazione ... Se un nome utente e una password debbano essere forniti o meno non è correlato al fatto che un servizio web sia fornito tramite (1) un canale crittografato e (2) autenticazione (ad esempio una chiave API).

Un servizio Web estremamente mal scritto può comunque richiedere l'invio di password in chiaro su HTTP. Una persona mal scritta può farlo su HTTPS (sicuro, ma una volta rotto, ad esempio attraverso un attacco man-in-the-middle , aperto agli abusi). Un servizio Web meglio scritto dovrebbe gestire la connettività del database internamente in base ad altri input, ad esempio ID di sessione, dopo la convalida dei controlli di autenticazione e titolarità.

Tornando al punto principale, il commento di @ marcus sulla tua domanda è essenzialmente. Gli aspetti di sicurezza non sono trattati in modo diverso dalle tecnologie "moderne" e riguardano questioni di implementazione come:

Se il tuo protocollo di comunicazione (prendendo in prestito un po 'dalla risposta di @ RobertHarvey) supporta la trasmissione di dati crittografati.
La struttura del payload del messaggio che viene inoltrata tra il server e il client.
- Il client dice semplicemente al server di mantenere l'indirizzo residenziale dell'utente o di connettersi a un database IP X.X.X.Xcon un nome utente e una password, quindi eseguire la queryINSERT INTO user_address ... ?
Come il server gestisce la connettività del database (che in realtà è isolato dal client, vedere il primo paragrafo).

Per maggiori informazioni:

— HJK
fonte