Як настільні програми спілкувалися з віддаленим сервером перед веб-сервісами?

11

У мене немає великого досвіду роботи з настільними програмами, але якби мені довелося створити настільний додаток сервера клієнтів, доступ до даних здійснювався б через веб-сервіс. Я вважаю, що доступ до даних через веб-сервіс забезпечує безпеку - мені не потрібно вводити ім’я користувача та пароль db-сервера тощо.

Перед веб-сервісами, як це зробили програми баз даних? Чи була передана вся важлива інформація про db в інсталяцію настільного додатка? Якщо так, як програмісти керували аспектом безпеки? Або програмісти використовували щось подібне до веб-сервісів?

programming-practices security

— Виє Гагрид
джерело

5

Були смішні речі для викликів віддалених процедур, такі як DCOM (розподілений COM), CORBA, Java RMI ... Я ніколи не розумів жодного з них, в той час як запитувати деякі дані через HTTP мав сенс миттєво. Я думаю , з допомогою веб - браузерів , кожен день з WebServices простіше :-) звертав уваги

— Маркуса

3

@marcus: напевно, тому, що в HTTP вбудований відповідь на запит, тоді як "деякий протокол через сокет" призводить до того, що всі винайдуть це колесо дещо іншої форми.

— Стів Джессоп

11

Залежно від того, що ви називаєте веб-службою.

До WSDL та REST ще існував HTTP, тому в основному все, що ви можете зробити зараз, можна було зробити і раніше.

Була відсутність рівномірності (саме тому WSDL та REST були створені в першу чергу), але це забезпечувало той самий рівень конфіденційності даних та безпеки, про який ви говорите.

Насправді ви також можете уникати використання HTTP: ви можете складати власний протокол, а також користувальницький сервер та користувацькі клієнти, які відкривали б розетку на цьому сервері та отримували потрібні їм дані (або розміщували дані). Тут ви втрачаєте всю перевагу стандартизації HTTP, але ще раз ви не надаєте клієнтам доступ до бази даних.

— Арсеній Муренко
джерело

17

Ага, ще тоді, коли у нас були палички та каміння.

До Інтернету ми мали щось зване архітектура "клієнт / сервер" та локальні мережі. Якщо ви не намагалися встановити зв’язок із сервером у декількох милях, ці мережі спрацювали чудово, щоб досягти майже нічого. Ви навіть можете встановити літери диска і використовувати з'єднання для файлових серверів, як-от віддалений жорсткий диск, якщо цього хочете. Якщо ви були за кілька миль, ви можете скористатися мережею з широкою площею, щоб зробити по суті те ж саме, хоча і з меншою швидкістю та більшими витратами.

Дешевим способом розмовляти дистанційно було передавання інформації по телефонних лініях за допомогою пристроїв, що називаються модемами, і якщо ви хотіли сфальсифікувати щось, де два комп’ютери спілкувалися один з одним за допомогою комп’ютерних програм, ви зробили це так само, як і сьогодні: встановивши протокол зв'язку. У цьому немає нічого магічного; обидві сторони просто повинні погодитись, що означають усі байти.

З самого раннього періоду Інтернету машини існували як спілкуватися через нього. Веб-сервіси - це лише останній аромат тижня.

— Роберт Харві
джерело

5

«Там нічого магічного взагалі про це, обидві сторони просто повинні домовитися про те , що всі байти середня.» І порядок байт :)

— ХІК

2

@hjk, це просто: маленький ендіан явно перевершує всі інші варіанти :-)

— Марк

3

Я б навіть зайшов, щоб сказати, що визначення Інтернету вимагає, щоб машини мали можливість спілкуватися через нього. Якщо вони не можуть цього зробити, це не Інтернет, це купа кабелів з маренням величі.

— Стів Джессоп

2

@SteveJessop: Ви помиляєтесь, " Це серія трубок ".

— Дедуплікатор

3

Просто для того, щоб прояснити деякі поняття спочатку ...

Я вважаю, що доступ до даних через веб-сервіс забезпечує безпеку - мені не потрібно вводити ім’я користувача та пароль db-сервера тощо.

Я думаю, ви суперечите поняттям (1) Безпека транспортного рівня (TLS) та (2) управління доступом у наведеному вище твердженні ... Незалежно від того, чи потрібно вводити ім’я користувача та пароль чи не пов’язано з тим, чи є веб-служба надається через (1) зашифрований канал та (2) аутентифікацію (наприклад, ключ API).

Вкрай погано написаний веб-сервіс все ще може вимагати надсилання паролів у прямому тексті через HTTP. Неправильно написаний може зробити це над HTTPS (захищений, але один раз розбитий, наприклад, через атаку " середнього" , відкритий для зловживань). Краще написана веб-служба повинна обробляти підключення до бази даних внутрішньо на основі інших вхідних даних, наприклад, ідентифікаторів сеансу, після перевірки автентифікації та прав прав.

Повернімось до основної суті, коментар @marcus до вашого питання - це по суті. Аспекти безпеки розглядаються не інакше, ніж "сучасні" технології, і вони охоплюють питання впровадження, такі як:

Чи підтримує ваш протокол зв’язку (трохи запозичивши відповідь @ RobertHarvey) передачу зашифрованих даних.
Структура корисного навантаження повідомлення, що передається між сервером і клієнтом.
- Клієнт просто каже серверу зберігати резидентну адресу цього користувача або підключитися до бази даних за IP-адресою X.X.X.Xз ім'ям користувача та паролем, а потім виконати запитINSERT INTO user_address ... ?
Як сервер управляє підключенням до своєї бази даних (яка реально ізольована від клієнта, див. Перший параграф).

Для отримання додаткової інформації:

— hjk
джерело