W jaki sposób aplikacje komputerowe komunikowały się ze zdalnym serwerem przed usługami internetowymi?

11

Nie mam dużego doświadczenia z aplikacjami komputerowymi, ale gdybym musiał utworzyć aplikację kliencką na serwerze, dostęp do danych byłby możliwy za pośrednictwem usługi internetowej. Wierzę, że dostęp do danych za pośrednictwem usługi sieciowej zapewnia bezpieczeństwo - nie muszę podawać nazwy użytkownika i hasła serwera db itp.

Jak to zrobiły aplikacje baz danych przed usługami internetowymi? Czy wszystkie ważne informacje dotyczące bazy danych zostały przekazane podczas instalacji aplikacji komputerowej? Jeśli tak, to w jaki sposób programiści zarządzali aspektem bezpieczeństwa? A może programiści używali czegoś podobnego do usług sieciowych?

programming-practices security

— Wycie Hagrid
źródło

5

Było zdumiewające rzeczy dla zdalnych wywołań procedur, takich jak DCOM (Distributed COM), CORBA, Java RMI ... Nigdy w pełni nie zrozumiałem żadnego z nich, a natychmiastowe proszenie o dane przez HTTP miało sens. Chyba za pomocą przeglądarek internetowych codziennego wykonane webservices łatwiej grok :-)

— Marcus

3

@marcus: prawdopodobnie dlatego, że HTTP ma wbudowaną odpowiedź na żądanie, podczas gdy „jakiś protokół przez gniazdo” powoduje, że każdy wynalazł to koło w nieco innym kształcie.

— Steve Jessop,

11

W zależności od tego, co nazywacie usługą internetową.

Przed WSDL i REST wciąż istniał HTTP, więc w zasadzie wszystko, co możesz teraz zrobić, można było zrobić wcześniej.

Brakowało jednolitości (dlatego przede wszystkim stworzono WSDL i REST), ale zapewniło ten sam poziom poufności i bezpieczeństwa danych, o którym mówisz.

W rzeczywistości możesz także uniknąć używania HTTP: możesz sporządzić własny protokół i użyć niestandardowego serwera i niestandardowych klientów, które otworzą gniazdo na tym serwerze i uzyskają potrzebne dane (lub opublikują dane). W tym przypadku tracisz wszystkie korzyści związane ze standaryzacją protokołu HTTP, ale ponownie nie dajesz dostępu do bazy danych klientom.

— Arseni Mourzenko
źródło

17

Ach, kiedy mieliśmy patyki i kamienie.

Przed Internetem mieliśmy coś, co nazywało się architekturą „klient / serwer” i sieciami lokalnymi. Jeśli nie próbujesz nawiązać połączenia z serwerem oddalonym o kilka mil, te sieci działały idealnie, aby osiągnąć większość celów. Możesz nawet ustalić litery dysków i użyć połączeń z serwerami plików, takimi jak zdalny dysk twardy, jeśli chcesz. Gdybyś był w odległości kilku mil, możesz użyć sieci rozległej, aby zrobić zasadniczo to samo, choć z mniejszą prędkością i większym kosztem.

Tani sposób na rozmowę zdalną polegał na przekazywaniu informacji między liniami telefonicznymi za pomocą urządzeń zwanych modemami, a jeśli chciałeś zmontować coś, w którym dwa komputery rozmawiały ze sobą za pomocą aplikacji komputerowych, zrobiłeś to w taki sam sposób, jak dzisiaj: ustanawiając protokół komunikacyjny. Nie ma w tym nic magicznego; obie strony muszą uzgodnić, co oznaczają wszystkie bajty.

Od bardzo wczesnych etapów Internetu istniały sposoby komunikacji między nimi. Usługi sieciowe to tylko najnowszy smak tygodnia.

— Robert Harvey
źródło

5

„Nie ma w tym nic magicznego; obie strony muszą tylko uzgodnić, co oznaczają wszystkie bajty.” I endianness :)

— hjk

2

@ hjk, to proste: little-endian jest wyraźnie lepszy od wszystkich innych opcji :-)

— Mark

3

Posunąłbym się nawet do stwierdzenia, że definicja Internetu wymaga, aby maszyny mogły się przez nią komunikować. Jeśli nie mogą tego zrobić, to nie jest internet, to wiązka kabli z ułudą wielkości.

— Steve Jessop,

2

@ SteveJessop: Mylisz się, „ To seria lamp ”.

— Deduplicator

3

Najpierw wyjaśnię kilka pojęć ...

Wierzę, że dostęp do danych za pośrednictwem usługi sieciowej zapewnia bezpieczeństwo - nie muszę podawać nazwy użytkownika i hasła serwera db itp.

Myślę, że łączysz koncepcje (1) zabezpieczeń warstwy transportowej (TLS) i (2) kontroli dostępu w powyższym zestawieniu ... To, czy nazwa użytkownika i hasło muszą zostać dostarczone, czy nie, nie ma związku z tym, czy usługa internetowa jest zapewniane przez (1) szyfrowany kanał i (2) uwierzytelnianie (np. klucz API).

Niezwykle źle napisana usługa internetowa może nadal wymagać wysyłania haseł w postaci zwykłego tekstu przez HTTP. Źle napisany może to zrobić za pomocą HTTPS (bezpieczny, ale raz złamany, np. Przez atak man-in-the-middle , otwarty na nadużycia). Lepiej napisana usługa internetowa powinna wewnętrznie obsługiwać połączenia z bazą danych na podstawie innych danych wejściowych, np. Identyfikatorów sesji, po sprawdzeniu autentyczności i kontroli uprawnień.

Wracając do głównego tematu, komentarz @ marcus do twojego pytania jest w gruncie rzeczy tym. Aspekty bezpieczeństwa nie są traktowane inaczej niż „nowoczesne” technologie, które obejmują kwestie związane z wdrożeniem, takie jak:

Czy Twój protokół komunikacyjny (pożyczenie trochę z odpowiedzi @ RobertHarvey) obsługuje transmisję zaszyfrowanych danych.
Struktura ładunku wiadomości przekazywana między serwerem a klientem.
- Czy klient po prostu każe serwerowi zachować adres zamieszkania tego użytkownika lub połączyć się z bazą danych pod adresem IP X.X.X.Xza pomocą nazwy użytkownika i hasła, a następnie uruchomić zapytanieINSERT INTO user_address ... ?
Jak serwer zarządza łącznością z bazą danych (która jest naprawdę odizolowana od klienta, patrz pierwszy akapit).

Po więcej informacji:

— hjk
źródło