как с сайта запустить приложение на клиенте

Как с сайта запустить приложение на клиенте

Необходимо чтобы на машине пользователя при нажатии на ссылку запускалась программа.
Программа у всех пользователей установленна в одно место. На рабочий стол.
Если пишу так:

то все работает, но браузер выдает предупреждение о том что открытие файла может быть опасно.

Подскажите можно ли заустить exe файл без сообщений и т.д.

Можно ли в моем случае использовать функции exec() или system()
И если можно то как?

Tanda, имеется возможность запуска приложения через COM.
Но для этого необходимо в приложение на кленте встроить COM-сервер.

я так делаю при вызове из web-системы графической карты (выполнено отдельным приложением) с наложением слоев уже внутри программы.

по Вашему, system() относится к языку разметки? К примеру, к HTML?

Tanda, ни в коей мере. Обьясню.

Ваш вопрос сотоит в том, является ли возможным запускать приложения на машине пользователя.
Поскольку Вы исопльзуете web-интерфейсы, отвечаю.

PHP. Это серверная технология. Т.е. php отрабатывает на сервере и никоим образом не имеет доступа к клиентской машине. Поэтому из php запустить приложение на машине клиента никак нельзя.

2) Использование технологии COM. Об этом ищите в поисковиках.

Источник

Как выполнить приложение на клиенте с веб-сайта?

У меня есть приложение в ASP.NET/С#, расположенное на сервере, моя проблема заключается в том, как запустить другое приложение (.exe), но в клиенте, который посещает веб-сайт (приложение на сервере)

* переведено с помощью Google

desarrollé un software en ext.net(asp + С#) elcual es una version actualizada de otro программное обеспечение переднего hecho en PowerBuilder (los llamaré v2 y v1 respectivamente). Por razones de tiempo, el software V2 no tiene todas las funcionalidades de V1, por lo cual, al finalizar el processimiento con V2 se debe abrir V1. Vale decir, estando en el browser usando V2 debiera poder abrir V1 (.exe)

К сожалению, это невозможно по соображениям безопасности. Если бы это было возможно, хакеры могли бы создать хаос на клиентских машинах. Тем не менее, вы можете быть в старой версии IE с использованием ActiveX. Это может потребовать минимального снижения уровня безопасности. Здесь ссылка каким-то образом:

Какова цель приложения, щелчок один раз может быть решением.

Тот факт, что вы не можете выполнять код непосредственно из браузера, не является неудачной вещью, это замечательная функция безопасности.

Очевидно, Sys Internals делает это, здесь: Windows SysInternals

но на самом деле их живая услуга просто дает вам ссылку на эту страницу: http://live.sysinternals.com/, откуда вы можете загрузить и выполнить локально.

Нам нужна более подробная информация о том, что должен делать ваш exe, поскольку это повлияет на используемую вами технологию, но правильный способ сделать то, что вы хотите сделать, либо:

Используйте ActiveX. Попросите пользователя установить элемент управления ActiveX один раз, и вы сможете запустить его с этого момента. ActiveX в основном запускает DLL на клиентском компьютере для вас. Есть некоторые ограничения на песочные боксы, и они выходят из моды, поскольку это только IE, и все больше и больше% Интернета не использует IE. Используйте Silverlight. Это будет легче программировать и будет больше похоже на то, с чем вы знакомы. Однако (я думаю) у него больше ограничений на песочницу, чем у ActiveX, но это кросс-браузер и кросс-платформа.

В Microsoft All-In-One Code Framework есть примеры как ActiveX, так и Silverlight. Я рекомендую пробовать All-In-One Sample Browser немного рубить по краям, но он работает. Существует также расширение VS2010, но оно не работает с экспресс-версией VS2010 или VS2008.

Для простого примера настройки ActiveX для веб-страницы см. Пример HTMLEmbedActiveX. Я не знаю конкретного примера Silverlight, чтобы указать вам.

Пожалуйста, предоставьте более подробную информацию в своем основном сообщении о том, что вы на самом деле пытаетесь сделать на стороне клиента, и я могу сказать вам, будет ли работать один из этих методов.

Источник

Взаимодействие сайта в браузере и локально запущенной программы

Иногда возникает необходимость передать данные между работающим в браузере приложением и программой, выполняющейся на той же системе, на которой запущен браузер. Это может понадобиться, например, если нам нужно поработать с оборудованием, подключенным локально. Считывателем смарт-карт, аппаратным ключом шифрования и так далее.

Первыми приходят в голову три способа решить эту задачу:

Почему не 1 и 2?

Первый пункт точно принесёт много боли, поддерживать браузеры придётся отдельно, сделать в плагинах для браузера можно далеко не всё. Всё же, теоретически, поработать со смарт-картами через плагины возможно. Но нужен способ проще.

Второй пункт просто реализовать, но для этой схемы придется делать авторизацию не только на сайте, но и в локальном приложении. Значит понадобится какой-никакой, но интерфейс, при смене пароля потребуется повторная авторизация и в программе. Плюс в корпоративных сетях будут дополнительные проблемы с сетью, у них часто доступ в интернет реализован через прокси-серверы с суровой фильтрацией и авторизацией, для настройки прокси тоже придётся делать интерфейс, не всегда можно отделаться автоматическим определением настроек. Далёкому от IT пользователю будет сложнее с этим работать, создадим больше работы техподдержке. Конечно, можно формировать установочный пакет индивидуально для каждого пользователя, чтобы убрать необходимость первичной авторизации, но это только добавит проблем.

При чем тут HTTPS?

Когда сайт работает по HTTPS, браузеры блокируют загрузку активного содержимого с помощью HTTP. Однако, по логике вещей, запрос к локальной машине по HTTP браузеры должны считать безопасным, и не должны блокировать его. Это оказалось не совсем так.
Таблица показывает результаты небольшого исследования поведения браузеров на платформе Windows:

В таблице приведено поведение браузеров при попытке сделать запрос по соответствующему адресу. Браузеры на движке Chromium ведут себя аналогично Chrome, а поведение Edge 44 аналогично поведению IE 11. Для HTTPS выпущен валидный сертификат, подписанный самоподписанным корневым сертификатом. Поведение для https://127.0.0.1 и https://localhost одинаковое, просто для 127.0.0.1 тогда нужно тоже выпускать сертификат, а сертификаты для IP адресов редко встречаются, так что опустим этот момент.

В Chrome всё работает. Chrome и IE используют системное хранилище сертификатов, поэтому в них работает и HTTPS. Firefox использует собственное хранилище сертификатов, поэтому не доверяет нашему самоподписанному сертификату. Firefox и IE не доверяют имени localhost, и это правильно, ведь никто не гарантирует, что оно разрешится в 127.0.0.1 (хотя они могли просто это проверить, как делает Chrome).

Главная проблема: IE не даёт обратиться к программе по HTTP. Значит возни с сертификатами нам не избежать.

Для работы с браузерами также потребуется указывать в программе правильные заголовки Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers (CORS).

SSL сертификат

Можно сделать DNS-запись для своего домена, например local.example.com, которая будет разрешаться в 127.0.0.1. Выпустить для этого домена SSL сертификат, распространять его вместе с программой. Придётся распространять закрытый ключ этого сертификата вместе с программой. Это совершенно не годится. А сертификат в программе еще и нужно будет обновлять.

IE не будет доверять самоподписанному SSL сертификату, его надо подписать доверенным корневым сертификатом (а он может быть и самоподписанный).

Можно сгенерировать корневой сертификат и SSL сертификат и распространять их с программой, добавляя в локальное хранилище сертификатов. Выглядит небезопасно. И тоже может возникнуть необходимость отозвать или обновить сертификат. Поэтому, сертификаты с ключами будем генерировать прямо на компьютере пользователя при первом запуске программы.

Создание сертификатов в C#

В примере эту работу делает метод RegisterSslOnPort в классе SslHelper.

HTTP-сервис в программе на C#

Для примера создадим endpoint, занимающийся сложением двух чисел. Важно тут установить правильные заголовки CORS, иначе браузер не будет выполнять запрос к нашему API.

Добавим инициализацию Nancy в наше приложение, и мы готовы к бою.

При первом запуске нужно сгенерировать сертификаты и поместить их в хранилище, запросив при этом соответствующие права. Для этих манипуляций служит класс SslHelper, в котором единственный публичный метод CheckOrCreateCertificates делает эту работу. В качестве параметров ему передаются SubjectName сертификатов. Метод проверяет нет ли нужных сертификатов и системе, если нет — создаёт их.

Для симуляции тяжелой работы и долгих задержек в примере добавим Thread.Sleep(1000) в вызовы нашего API.

На этом приложение готово к запуску, перейдём к вебу.

Веб-приложение

Как понятно из таблицы поведения браузеров, каким-то одним эндпоинтом обойтись не получится, придётся использовать как минимум два:

В веб-приложении нам нужно определить, если мы в IE (или Edge) – использовать HTTPS, если нет – HTTP. Можно сделать надёжнее и не выяснять в каком мы браузере, а просто попробовать выполнить запрос к методу GET /Calc нашего API, если запрос успешен – работаем, если нет – пробуем другой протокол.

Всё это нужно только если веб-приложение само использует HTTPS, потому что при использовании протокола HTTP, браузеры не накладывают ограничений на запросы, нужны только правильные заголовки CORS.

В angular – приложении создадим сервис InteractionService, который будет выполнять проверку доступности локального эндпоинта сначала по HTTP, потом по HTTPS. Проверку выполняет метод checkAvailability, а результат проверки доступен при подписке на переменную available$ типа BehaviorSubject с начальным значением false.

Работу по сложению чисел поместим в компонент AppComponent. При нажатии кнопки “Calculate”, веб-приложение делает запрос к GET /Calc/Add?num1=&num2=. Ответ или ошибка отображается в поле Result.

При отладке, даже по HTTPS, можно не заметить проблем, так как домен для запросов будет один и тот же – localhost. Поэтому тестировать приложение нужно с другим доменным именем.
Чтобы максимально упростить работу по развертыванию веб-приложения воспользуемся сервисом https://stackblitz.com, это веб-IDE для angular и не только, со вкусом VSCode. Готовое приложение доступно по ссылке.

В интерактивном режиме на stackblitz приложение не будет работать, нужно открыть его в отдельной приватной вкладке, или в другом браузере по адресу https://angular-pfwfrm.stackblitz.io.

Как попробовать?

Веб-приложение удобно запустить с помощью stackblitz, просто перейдя по ссылке https://angular-pfwfrm.stackblitz.io.

Можно запустить веб-приложение локально.

для этого нужно клонировать репозиторий:

в папке AngularWebApp нужно выполнить команды:

Веб-приложение будет доступно по адресу https://localhost:4200/

Локальное приложение можно либо скомпилировать из примера (открыть CsClientApp.sln из папки CsClientApp) с помощью Visual Studio и запустить, либо использовать скрипт для программы LINQPad.

Безопасность

Важно правильно формировать заголовки CORS в реальном приложении, чтобы злодеи с других сайтов не могли обратиться к нашей программе. Если же у злодея есть возможность работать с привилегиями пользователя на его компьютере и обходить проверку CORS, значит он и так сможет сделать всё, что может делать наша программа.

В любом случае, программа должна работать с минимальными правами, а если делает что-то чувствительное с документами, надо добавить в неё запросы на подтверждение операций.

Вывод

Несложная на вид задача на деле оказалась довольно объемной, да еще и требующей дополнительных костылей для работы с сертификатами.

Этот подход хорошо себя показал в реальном приложении. Конечно, чтобы использовать код из примера, нужно добавить нормальную обработку ошибок.

Никто на Virustotal на эту программу не реагирует, а хотелось бы! Зато если собрать установочный пакет в InnoSetup, пара третьесортных антивирусов начинает на него срабатывать. Помогает от этого избавиться подписывание установщика с помощью code signing certificate.

Автоматическое обновление программы здесь оставлено за кадром, но оно точно не будет лишним в реальном приложении. Для управления автоматическим обновлением хорошо подходит Squirrel. Еще с помощью squirrel удобно удалить наши сертификаты из системы при удалении программы.

Источник

Windows-приложения в веб-браузерах пользователей. Свое облако с блэк-джеком и т.д

Идея запускать приложения не на компьютере пользователя, а на удаленном сервере, и транслировать изображение пользователю по сети – не нова, и давно «витает в воздухе». Согласитесь, идея хорошая: ведь для установки любого нового ПО на свой компьютер необходимо разобраться с политикой лицензирования (кому это актуально), найти дистрибутив (желательно, без вредоносного ПО внутри), установить и настроить ПО — иногда просто руки опускаются. Кроме того, подход с трансляцией ПО снимает необходимость в своем производительном «железе», что становится актуальным в свете ежегодного роста продаж планшетных компьютеров и смартфонов. Да и интернет есть повсюду в мегаполисах: слушать музыку и смотреть кино онлайн, в конце концов, все уже давно привыкли.

Вот только ни одного полнофункциональной разработки, подходящего для применения в сети Интернет до сих пор так и не видно. Мы подумали, что это никуда не годится и решили сделать ее.

Давайте поподробнее

С моей стороны будет, наверное, не совсем честным не упомянуть про вполне себе существующие, и даже неплохо себя зарекомендовавшие Citrix XenApp и Microsoft App-V. Оба продукта неплохо справляются со своей задачей в крупных организациях, но вот беда: оба решения малопригодны для публичного предоставления сервиса (то есть, для сети Интернет). Виной тому технические особенности, ведь эти системы изначально проектировались для интеграции заказчику. Причем речь идет в первую очередь о крупном бизнесе, так как среднему и малому бизнесу такие системы не по карману. Да и клиентское ПО надо ставить на пользовательские устройства, разбираться, настраивать. На практике оказывается, что не для любых устройств есть клиенты (я про планшеты. Смартфоны и вовсе не поддерживаются), несмотря на заверения дистрибьюторов. Стоит ли говорить, что попытки построения публичного сервиса на базе данных продуктов ничем хорошим не заканчивались, насколько мне известно.

А почему бы не сделать систему, способную транслировать Windows-приложения именно для глобальной сети, подумали мы?

Говоря про Windows-приложения, мы имеем в виду любое программное обеспечение, способное функционировать под управлением операционной системы Microsoft Windows. Почему взяли фокус именно на Windows-приложения? Все очень просто: Windows-приложения – это приложения для бизнеса, для работы, для учебы, приложения, которыми пользуются (и, что немаловажно, умеют пользоваться) миллиарды людей по всему миру. Количество приложений уже разработанных под Microsoft Windows, полагаю, исчисляется миллионами, что представляет собой огромный неисчерпаемый функционал, который было бы, на мой взгляд, здорово аккумулировать в одном месте.

В качестве главного критерия системы была выбрана простота понимания для конечного пользователя, чтобы даже моя мама, привыкшая работать с уже установленным и настроенным ПО на своем ноутбуке не самой последней модели, легко разобралась.

Еще одним важным критерием стало желание поддерживать различные типы современных устройств (персональные компьютеры под управлением различных OS, планшеты, мобильные устройства, современные телевизоры, поддерживающие технологию smart TV и другие). Решение напрашивалось само собой: транслировать windows-приложения надо с удаленного сервера в веб-браузеры конечных пользователей, ну или на веб-страницу, если быть более точным. Вот только как это сделать?

Реализация

Сервер приложений является ядром и наиболее не простой частью разрабатываемой системы. Передача изображения от запущенного на сервере ПО осуществляется с помощью снятия скрин-шотов и передачей полученных кадров в режиме реального времени. Изображение разбивается на области, и пользователю передаются только изменения для экономии трафика. Изначально планировалось использовать технологию Desktop Duplication API, но так как она может дуплицировать только рабочий стол целиком, а нам нужны окна, то от нее пришлось отказаться. Модуль создания скриншотов в итоге пришлось разрабатывать самостоятельно. Для разработки кодека в качестве «образца для подражания» был принят FreeRDP WebConnect, серверную часть естественно писали сами. Для передачи событий клавиатуры и мыши приложениям имитируются события на стороне сервера с использованием функций send input.
Файловый сервер и сервер управления представляют меньше интереса, по этой причине не будем на них заострять внимание.

На данный момент бета-версия выглядит так:

И немного импрессионизма в Gimp от автора статьи

Источник

Клиент-серверная архитектура в картинках

Знакомая картинка? А вы ведь постоянно сталкиваетесь с этой архитектурой — когда покупаете билет в кино онлайн, бронируете путевку на море или записываетесь к врачу.

На клиент-серверной архитектуре построены все сайты и интернет-сервисы. Также ее используют десктоп-программы, которые передают данные по интернету. Поэтому ИТ-специалисту нужно понимать, что это такое и как работает.

Об этом я и расскажу в статье. Объясню на пальцах, с примерами и забавными картинками =) Если вы больше любите видео-формат, можно посмотреть мой ролик на youtube на ту же тему.

Содержание

Что это и как работает

Вот есть у нас некий Вася, который решил купить машину. Такую, как в рекламе — быструю, мощную, красивую! Только стоит она как хвост самолета, у Васи таких денег нет.

Конечно, Вася может подкопить несколько лет, а потом уже покупать машину. Но ведь хочется здесь и сейчас! Да и средство передвижения нужно…

А еще Вася не умеет копить — получил зарплату, закупился основным, оплатил жилье, всё! Остальное можно потратить. Для таких людей есть банки, куда можно прийти и взять деньги в кредит.

Конечно, потом вы будете переплачивать, возвращая их назад. Проценты-то конские. Но зато уже сейчас можете позволить купить себе что-то дорогое.

Вася подумал, прикинул и сказал:

— Да, хочу именно так! 100 рублей с зарплаты платить в банк могу, а откладывать — нет. Потрачу.

Поэтому Вася идет в банк и говорит:

— Я Василий Иванов, хочу автокредит на 1000р.

У Кати есть специальная программа для проверки данных по клиентам. Эта программа может быть как web, так и desktop:

Катя вбивает в программу «Василий Иванов» и получает информацию по клиенту — есть ли он в черных списках? Была ли кредитная история раньше? И так далее. Но что происходит в потрохах приложения?

Катя ввела данные на клиенте. Но когда она нажала «проверить», клиент отправил запрос на сервер:

— Дай мне информацию по Васе Иванову!

Сервер отправил запрос в БД, базу данных:

— Select * from clients where fio = ‘Василий Иванов’. (Дай мне всю информацию по ФИО ‘Василий Иванов’)

— Вот тебе все, что нашла.

Сервер вернул эту информацию клиенту:

А клиент уже отрисовал ее для Кати:

— Ага, кредитная история хорошая.

И делает предложение Васе:

— Пожалуйста, если хотите взять кредит, то мы готовы выделить 1000р на 12 лет под 80% годовых. Устроит?

— Да, меня всё устраивает, давайте скорее деньги, и я побежал за машиной!
Все счастливы, все довольны.

Катя даже не догадывается, какой путь проделали данные в программе, когда она вбила туда ФИО своего клиента. Но мы с вами должны узнать, что же это за путь такой? И к чему все эти сложности? Почему именно такая структура? Почему есть клиент, почему есть сервер?

Зачем нужен клиент

Тут все просто — с клиентом работает пользователь. Он нужен, чтобы превратить байтики программного кода в красивую и понятную картинку. Пользователь — не программист, он не понимает язык программирования или sql. Он понимает формочки и кнопочки. Их в клиенте и рисуем.

Зачем нужен сервер

Клиентов может быть много. В примере с банком у нас может быть по 10 отделений в 10 городах России, а в каждом отделении по 10 операционисток. Тысяча Катек, и у каждой отдельный компьютер.

А мы ведь хотим, чтобы приложение работало быстро. Чтобы оно не тупило и не зависало, нервируя операциониста и заставляя клиента ждать. Значит, машина нужна мощная. Но если делать мощным каждый компьютер операциониста, денег придется вложить очень много!

Поэтому мы выносим всю основную логику на сервер. И вот его уже делаем мощным! А клиентские машины могут быть дешевыми, потому что на них остается лишь логика в стиле «запросить информацию и красиво отрисовать».

Нет дублирования кода

Если бы у нас были только клиентские машины, на каждой из них хранился бы одинаковый код по обработке логики, лежала вся база данных, все справочники террористов и прочая. Но так как сервер и БД вынесены в отдельные звенья, с клиентской машины освобождается куча места… И кода.

Не надо дублировать код, ведь вся основная логика вынесена на более мощный сервер.

На сервере и в базе хранится информация, недоступная простому операционисту. Это:

Есть операционисты, готовые за денюшку слить информацию о клиентах. Есть нечистые на руку люди, готовые невзначай заглянуть через плечо. А, может, клиент сам такой человек. Представляете, отпихивает Вася хрупкую Катю, садится за ее компьютер, и переводит себе на счет миллионы, пока его не повяжет охрана.

Зачем нужна база

При чем же тут БД? Вот у нас есть наш сервер, пусть он и хранит всю информацию. Бывает и так, иногда база просто не нужна и у нас остается двузвенная архитектура клиент-сервер.

В таком случае все данных сервер хранит в памяти. Вот только если сервер упадет, или просто перезагрузится — вся информация будет потеряна. Все, что было в памяти, стирается при выключении системы.

БД (база данных) — отдельный программный продукт, который позволяет:

Да, базы может не быть. Но когда она есть, мы уверены в сохранности данных и легко можем по ним поискать.

Плюсы архитектуры

Резюмируем плюсы архитектуры:

Минусы архитектуры

Упало одно звено — все отдыхают

Если упал сервер или отвалилась база, то есть испортилось 1 звено — всё, все в ступоре, все отдыхают. Сотни, тысячи, да хоть миллионы клиентов если есть — никто не может работать. Все операционистки грустно смотрят на окно «Простите, что-то пошло не так» и разводят руками перед клиентом.

Именно поэтому в бизнес-критичном ПО архитектуру усложняют и даже дублируют. Банк с тысячами операционистов не может позволить себе простой. Поэтому они используют кластер серверов — один упал, остальные работают.

Как в таком случае клиент понимает, куда ему отправлять запрос?

Перед серверами ставят балансировщик, и клиент шлет запрос туда. Сколько бы серверов не поставили в кластер, клиенту это не интересно. У него есть один URL — адрес балансировщика.

И вот с клиента поступает запрос:

— Дай мне всю информацию по Васе Иванову.

— Ребята, новый запрос! Кто меньше загружен?

— У меня 5 запросов в очереди стоит.

Балансировщик отправляет запрос второму серверу.

Такая схема используется для высоконагруженного приложения — когда запросов поступает так много, что один сервер с ними просто не справляется.

Facebook, amazon, google — туда заходят миллионы пользователей. Один сервер с ними не справится. Поэтому ставят кластер, а балансировщик делит между ними нагрузку. И в таком случае в кластере может быть не 2 сервера, а 10, 15, сколько нужно, столько и ставим.

При этом мы можем точно также балансировать базу данных. У нас может быть несколько копий баз данных на самых разных машинах, и балансировщик отправляет запросы то к одной, то ко второй.

Такая схема называется горячий резерв — когда у нас есть несколько серверов, работающих в параллель, и балансировщик распределяет нагрузку между ними.

При этом может быть и схема холодного резерва — когда у нас второй сервер является резервной копией «на всякий случай». Все запросы идут на первый сервер, второй отдыхает.

Но если с первым сервером что-то случится и он помрет, балансировщик перенаправит нагрузку на второй сервер:

В это время у администраторов будет время разобраться с проблемой на сервере 1.

Схема холодного резерва используется тогда, когда один сервер способен выдержать нагрузку и выдавать хорошую скорость работы. Но приложение при этом бизнес-критичное и простой неприемлем.

Простой может быть не только потому, что случилось что-то плохое. Есть еще штатное обновление приложения. Обе схемы резервирования позволяют обновляться безболезненно. Если в кластере два сервера, обновление будет выглядеть так:

Таким образом, схемы резервирования помогают нам устранить проблему «упало 1 звено — все отдыхают». Клиент никогда не узнает, что один или несколько серверов в кластере сдохли, у него всё как работало, так и работает.

Высокая стоимость оборудования

Сервера стоят дорого. Туда нельзя поставить обычный SSD как для домашнего компьютера. Почему? Потому что к железу для серверов совсем другие требования по надежности + есть поддержка специфичных функций:

— у HDD это специальная микропрограмма контроллера, которая оптимизирована для работы диска в RAID, дома это не нужно.

— у SSD это наличие группы конденсаторов, которые хранят энергию на случай отключения питания, чтобы хватило времени скинуть из DDR кэша данные в энергонезависимую память и данные не побились.

SSD — быстро работающий диск, HDD — обычный. RAID — когда мы N дисков вместе соединили, а DDR кэш — это оперативная память

Плюс у серверных решений гарантия обычно гораздо дольше: 5 лет, а не год.

По цене отличаются в 2 раза. Например, SSD:

Вроде не сильно отличается, да? Но смысл в том, что для дома 1 тб хватает за глаза — и фоточки все влезут, и кино, и куча приложений… А для базы данных иногда и 10 тб будет мало. А если делать кластер, то умножаем стоимость на 2, если не больше. Поэтому и разница в цене кажется огромная, но при пересчете на гигабайт небольшая выходит.

Не забывайте, что дома вам просто надо свои фоточки держать, да и те обычно в облаке. А на сервере бизнес-критичный функционал, который жрет дофига ресурсов и который надо дублировать на случай «вдруг первый сдохнет».

Нужно нанять сисадмина ツ

Нам нужно нанять сисадмина, который будет следить за всеми нашеми серверами приложения и БД. Добавляем его зарплату к стоимости оборудования!

Что тестировать

Чтобы понимать, что тестировать, надо понимать, с чем имеет дело человек.

Пользователь работает с клиентом. Это может быть web или desktop приложение, не суть. Операционистке Кате дали рабочее место, показали какую программу запускать и как с ней работать. Она знать не знает о наличии серверов и БД, она работает только с клиентом.

Поэтому тестировщик в первую очередь проверяет клиент! Потому что сервер может работать идеально, вы можете даже написать тесты на уровне API и они все будут зелененькие, и кажется, что все зашибись! А пользователь загрузит отчет и увидит ошибку. Ой.

Сервер работает, на клиенте ошибка. И плевать на сотни «зеленых» автотестов. У пользователя все равно ошибка. И наша задача — посмотреть с его точки зрения.

Однако, если у вас есть доступ к серверу приложения и его базе данных — стоит проверять и их тоже! Так мы можем увидеть «будущий баг». Например:

— Ну, наверное, их и не заполняли.

А их заполняли! Просто сохранение криво сработало. Поэтому, если у нас только черный ящик, то нужно проверять, «а реально ли сохранились данные?». Сохранили? Откройте карточку в новом окне или вызовете информацию через API-метод.

Если доступ к базе есть — просто проверьте по ней, что все хорошо. Если есть доступ к серверным логам — проверьте их на наличие ошибок.

Помимо простых пользователей бывают злые люди, которые пытаются встрять в наше приложение и своровать деньги / данные. Они используют не клиент или сервер — туда у них доступа нет. Они пытаются перехватить данные в пути от клиента к серверу, или от сервера к БД.

Ну а раз нехорошие люди могут это сделать, то тестировщик тоже должен это уметь! Потому что тестировщик предоставляет информацию о нашем продукте.

Тестировщик изучает уязвимости и потом рассказывает команде:

— Ребята, вот я проверил, у нас есть такие-то и такие-то потенциальные дыры. Давайте подумаем, надо нам их как-то закрывать или нет.

То есть не факт, что исправлять проблему будут. Может, у вас некритичное приложение — данные не утекут, деньги вы не храните. Тогда и заморачиваться лишний раз никто не будет, потому что тестировать на защищенность — дорого, специалистов мало.

Но какие-то базовые проверки типа sql-иньекций или XSS-атак стоит изучить и проверить на своем приложении. Хотя бы чтобы понять их критичность. Ведь если атака сломает клиент — ну и пусть, сам себе буратино. А если атака положит сервер, это уже не очень хорошо. И надо хотя бы знать, от чего это бывает.

Итого

Клиент — та программа, с которой работает пользователь. Он знать не знает, это у него на компьютере программа целиком, или где-то за ней прячутся сервер с базой, а то и целый RAID. Он работает в браузере или с desktop-приложением. И всё, что ему нужно знать — это «куда тут тыкать».

Клиенту не нужно много памяти, места на диске и других ресурсов. Поэтому рабочие места относительно дешево стоят. А это именно то, что нам нужно, особенно если нужно закупить оборудование для тысяч операционисток банка.

Сервер — компьютер, на котором хранится само приложение. Весь код, вся логика, все дополнительные материалы и справочники. Например, справочник адресов ФИАС или справочник юр лиц ЕГРЮЛ — они тоже занимают место, как сами по себе, так и в памяти приложения.

Иногда говорят «сервер приложения» и «сервер БД». Это нормально, ведь фактически сервер — это просто машина, компьютер. А базу и сервер приложения обычно хранят на разных машинах, ради безопасности. В таком случае, если говорят «сервер приложения» — речь о втором звене нашей схемы.

Приложения бывают самые разные. Есть ресурсоемкие, им нужно много памяти и места на диске. Есть «легкие», которые можно развернуть даже на домашнем компьютере.

БД (база данных) — хранилище данных. Тут вы можете легко поискать информацию + уверены в том, что она сохранится, даже если в приложении что-то сломается. Подробнее о ней — в статье «Что такое База Данных (БД)»

Сколько места нужно под базу, зависит от количества данных. Есть огромные базы в банках, где и 1тб будет мало. А есть совсем небольшие, которые вы можете установить на своей машине. Например, XAMPP можно поставить. И врядли вы напихаете туда столько данных, что у вас не останется под них место.

Отдельной базы может не быть, тогда структура станет двузвенной: клиент-сервер. И все!

Схема условная, в реальной жизни у нас как минимум будет больше клиентов. А если приложение высоконагруженное, то будет несколько серверов и несколько баз данных:

PS — больше полезных статей ищите в моем блоге по метке «полезное». А полезные видео — на моем youtube-канале

Источник