Модулі/HTTP - OpenSCADAWiki

# Модулі/HTTP

This page is a translated version of the page Modules/HTTP and the translation is 100% complete.

English • ‎mRussian • ‎Українська

Модуль | Ім'я | Версія | Ліцензія | Джерело | Мови | Платформи | Тип | Автор | Опис
--- | --- | --- | --- | --- | --- | --- | --- | --- | ---
HTTP | HTTP-реалізація | 3.12 | GPL2 | prot_HTTP.so | en,uk,ru,de | x86,x86_64,ARM | Протокол | Роман Савоченко | Надає підтримку HTTP для WWW базованих користувацьких інтерфейсів. Завдання (To Do):

Модуль транспортного протоколу HTTP призначено для реалізації підтримки мережевого протоколу HTTP(Hypertext Transfer Protocol) у OpenSCADA.

Протокол HTTP використовується для передачі вмісту WWW. До прикладу, через HTTP передаються наступні типи документів: html, xhtml, png, javascript і багато інших. Підтримка HTTP у OpenSCADA разом із транспортом Sockets і SSL, дозволяє реалізовувати різні користувацькі функції на WWW інтерфейсі. Модуль первинно реалізує два основних методи HTTP протоколу GET, POST, і наразі будь який метод HTTP. Модуль забезпечує контроль цілісності HTTP-запитів та, спільно з транспортом Сокети і SSL, дозволяє "збирати" цілісні запити з їх фрагментів, а також забезпечувати утримання з'єднання "живим" (Keep-Alive).

Для гнучкого підключення користувацьких інтерфейсів до даного модуля, використовується модульний механізм у межах самого цього модуля. У ролі модулів використовуються модулі підсистеми "Користувацькі інтерфейси" з додатковим інформаційним полем "SubType", зі значенням "WWW".

У запитах до Web ресурсів прийнято використовувати URL(Universal Resource Locator). Відтак, URL передається як основний параметр через HTTP. Перший елемент URL запиту використовується для ідентифікації модуля UI. Наприклад, URL "http://localhost:10002/WebCfg" означає звернення до модуля "WebCfg" на хості "http://localhost:10002". У випадку помилкового визначення ідентифікатору модуля, або при звернені взагалі без ідентифікатору, модуль генерує інформаційний діалог про вхід та вибір одного з доступних користувацьких інтерфейсів. Приклад діалогу наведено на рисунку 1.

Рис.1. Діалог вибору модуля WWW-інтерфейсу.

Модулем підтримується багатомовність, яка вмикається динамічним перекладом повідомлень OpenSCADA.

Мова кінцевого користувацького інтерфейсу визначається шляхом та у послідовності:

- URL параметр "lang".
- Мова користувача, що увійшов.
- Мова Web-браузеру з HTTP властивості "Accept-Language".
- Загальна мова процесу OpenSCADA.

Отримана таким чином мова використовується для побудови інтерфейсів цього модуля і передається WWW під-модулям у HTTP властивості "oscd_lang", через аргумент "vars" функції узагальнення, "GET" і "POST".

Для конфігурації і керування цим модулем надається конфігураційна сторінка інтерфейсу керування OpenSCADA (Рис.3), де можете здійснювати:

- Контроль за активними сеансами автентифікації.
- Конфігурацію:
  - Правила доступу для заборони і дозволу. Кожний рядок є окремим правилом і ви можете використовувати шаблони на кшталт "*/WebVision/*" або регулярні вирази на кшталт "/[^/]+/WebVision/.+/". Корисні записи для:
    - Заборонено:
      - "*/WebCfgD/*" — модуль WebCfgD цілком;
      - "*/WebVision/*tmplSO/*" — проєкт СВУ "tmplSO" модуля WebVision.
    - Дозволено:
      - "*" — все, виключаючи заборонене;
      - "/^[^/]+/[^/]*$/" — сторінки модуля з усіма їх ресурсами;
      - "*/login/*" — сторінка авторизації-входу;
      - "/^[^/]+/WebVision/[^/]*($|\?)/" — основна сторінка модуля WebVision без доступу до проєктів СВУ;
      - "/^[^/]+/WebVision/.+_aviariesOril\d*/.*/" — проєкт СВУ "aviariesOril" модуля WebVision;
      - "/^[^/]+/WebVision/Archive/.*/" — доступ до архівних даних примітиву Протокол для усіх проєктів WebVision.
  - HTML-шаблон користувацького інтерфейсу і користувацької головної сторінки. У полях HTML-шаблону має вказуватися адреса до файлу HTML/XHTML, який буде використано у формуванні внутрішніх-сервісних інтерфейсів та головної сторінки. Внутрішні-сервісні інтерфейси, це наприклад: обрання модулів, сторінка авторизації і подібне у WEB-модулів. Від шаблону вимагається коректність XHTML, яка дозволяє розібрати файл XML-парсером, а також наявність мітки "#####CONTEXT#####" у місці розташування динамічного вмісту, що обов'язково для внутрішніх-сервісних інтерфейсів. Ресурсні файли шаблонів представлено зображеннями, CSS і JavaScript файлами, та які шукаються від теки у якій вказано розташування файлу шаблону і від поточної теки. Для іншого файлу шаблону до мови, Ви можете додати суфікс мови у кінець цього файлу "{Мій Шаблон}_{мова}.html", але обирати у конфігураційних полях основний-базовий файл шаблону "{Мій Шаблон}.html". У випадку виявлення помилок у шаблоні буде використано стандартний вбудований інтерфейс. У якості прикладу шаблонів можете подивитися такі найбільш вживані:
    - Шаблон внутрішнього-сервісного інтерфейсу та головної сторінки включаючи індекс модулів.
    - Шаблон головної сторінки із прямим посиланням на головний інтерфейс АГЛКС за допомогою модуля UI.WebVision і без індексу WEB-модулів.
    - Шаблон головної сторінки із прямим переспрямуванням на головний інтерфейс АГЛКС за допомогою модуля UI.WebVision.
  - БД активних сеансів аутентифікації передбачає зовнішню таблицю активних сеансів аутентифікації — "HTTP_AuthSessions", яка вмикається для непорожнього значення і надає можливість спільного використання аутентифікації між різними станціями OpenSCADA і її короткого збереження на час вимкнення станції.
  - Простір генерації UID автентифікації, доступне зі спільною таблицею сеансів автентифікації для гарантування відмінності "печеньок" (cookie) для різних процесів OpenSCADA.
  - Час життя, перелік користувачів дозволених до аутентифікації і встановлення автоматичного входу.

Рис.3. Сторінка налаштування модуля.

## 1 Аутентифікація

Модулем підтримується аутентифікація у OpenSCADA при надані доступу до модулів WEB-інтерфейсів (рис.2).

Рис.2. Діалог аутентифікації у OpenSCADA.

Аутентифікація цим модулем здійснюється "печеньками" (cookies) із динамічною назвою і простором ІД користувача, де назва "печеньки" (cookie) "oscd_UID" і використовується простір ІД користувача у роботі із спільною таблицею сеансів автентифікації, та назва "oscd_UID_{PrjNm}" у роботі без неї.

Для полегшення роботи з Web-інтерфейсами, модуль передбачає можливість автоматичного входу від ім'я вказаного користувача. Конфігурація автоматичного входу здійснюється на сторінці налаштування модуля (рис.3). Автоматичний вхід здійснюється за збігом адреси, вказаної у стовпчику "Адреса", і від ім'я користувача, вказаного у стовпчику "Користувач".

Для більшої безпеки, можете визначити тільки Web-користувачів у переліку користувачів дозволених до аутентифікації.

## 2 Модулі WEB-інтерфейсу

Модулі користувацького інтерфейсу (UI), які призначені для спільної роботи із модулем HTTP, мають встановлювати інформаційне поле "SubType" значенням "WWW" та поле "Auth" значенням "1", якщо модуль потребує автентифікації при вході. Для зв'язування модуля HTTP і модулів UI використовується розширений механізм комунікації. Цей механізм передбачає експорт інтерфейсних функцій. У даному випадку, UI модулі мають експортувати лише одну загальну функцію для усіх методів:

- void HTTP(const string &meth, const string &uri, string &page, vector<string> &vars, const string &user, TProtocolIn *iprt);:

    meth — метод запиту;
    uri — локальна адреса запиту;
    page — сторінка з відповіддю;
    sender — адреса відправника;
    vars — змінні запиту;
    user — користувач, може містити попереднього користувача у другому рядку;
    iprt — посилання на об'єкт вхідної частини протоколу.

Або наступні різні функції окремо для GET і POST методів:

- void HTTP_GET(const string &uri, string &page, vector<string> &vars, const string &user, TProtocolIn *iprt); АБО

  void HttpGet( const string &uri, string &page, const string &sender, vector<string> &vars, const string &user ); — Метод GET з параметрами:
    uri — локальна адреса запиту;
    page — сторінка з відповіддю;
    sender — адреса відправника;
    vars — змінні запиту;
    user — користувач, може містити попереднього користувача у другому рядку;
    iprt — посилання на об'єкт вхідної частини протоколу.

- void HTTP_POST(const string &uri, string &page, vector<string> &vars, const string &user, TProtocolIn *iprt); АБО

  void HttpPost( const string &uri, string &page, const string &sender, vector<string> &vars, const string &user ); — метод POST з параметрами:
    uri — локальна адреса запиту;
    page — сторінка з відповіддю та вмістом тіла запиту POST;
    sender — адреса відправника;
    vars — змінні запиту;
    user — користувач, може містити попереднього користувача у другому рядку;
    iprt — посилання на об'єкт вхідної частини протоколу.

Надалі, у випадку надходження HTTP запиту "GET" буде викликатися функція "HTTP_GET" або "HttpGet", а у випадку запиту "POST" буде викликатися функція "HTTP_POST" або "HttpPost", у відповідному модулі UI, або функція "HTTP" для будь якого методу.

## 3 Функція вихідних запитів користувацького API

Функція вихідних запитів messIO() оперує обміном вмістом HTTP-запитів, загорнутими у XML-пакети. Структура запиту має вигляд:

    <req Host="host" HostHdr="host" URI="uri">
      <prm id="pId">pVal</prm>
      <cnt name="cName" filename="cFileName">
        <prm id="cpId">cpVal</prm>
        cVal
      </cnt>
      reqVal
    </req>

  Де:
  - req — метод запиту, підтримується методи "GET" та "POST".
  - host — адреса вузла HTTP-Серверу у форматі {HostAddr}:{HostIp}, коли дане поле опущено у обох атрибутах "Host" і "HostHdr", то використовується адреса транспорту; атрибут "HostHdr" використовується для встановлення адреси лише до HTTP-Заголовку без зачипання вихідного транспорту.
  - uri — адреса ресурсу на HTTP-Сервері, зазвичай файл або тека.
  - pId, pVal — ідентифікатор та значення додаткового HTTP-Параметру. HTTP-Параметрів може бути вказано багато, окремими prm тегами.
  - cName, cFileName, cVal — ім'я, ім'я-файлу та значення елементу вмісту POST-запиту. Елементів вмісту може бути вказано багато, окремими cnt тегами.
  - cpId, cpVal — ідентифікатор та значення додаткового параметру вмісту. Параметрів вмісту може бути вказано багато, окремими prm тегами;
  - reqVal — одинокий вміст POST запиту.

Результатом запиту є відповідь зі структурою:

    <req Host="host" HostHdr="host" URI="uri" err="err" Protocol="prt" RezCod="rCod" RezStr="rStr">
      <prm id="pId">pVal</prm>
      respVal
    </req>

  Де:
  - req — метод запиту.
  - host — адреса вузла HTTP-Серверу.
  - uri — адреса ресурсу.
  - err — помилка, яка виникла під час запиту. У випадку вдалого запиту це поле порожнє.
  - RezCod, RezStr — результат запиту у вигляді коду та тексту.
  - pId, pVal — ідентифікатор та значення додаткового HTTP-Параметру відповіді. HTTP-Параметрів може бути багато, визначені окремими prm тегами.
  - respVal — вміст відповіді.

Наведемо формування GET та POST запитів на мові JavaLikeCalc.JavaScript, у якості прикладу використання даної функції у користувацьких процедурах:

    //GET запит HTML сторінки
    req = SYS.XMLNode("GET");
    req.setAttr("URI","/");
    SYS.Transport.Sockets.out_testHTTP.messIO(req,"HTTP");
    test = req.text();

    //GET запит та збереження файлу
    req = SYS.XMLNode("GET");
    req.setAttr("URI","/oscadaArch/Work/openscada-0.9-r2188.tar.lzma");
    SYS.Transport.Sockets.out_testHTTP.messIO(req,"HTTP");
    if(!req.attr("err").length) SYS.fileWrite("/var/tmp/recvFile.tmp", req.text());

    //POST запит
    req = SYS.XMLNode("POST");
    req.setAttr("URI","/WebUser/FlowTec.txt");
    cntNode = req.childAdd("cnt").setAttr("name","pole0").setAttr("filename","Object2-k001-100309-17.txt");
    cntNode.childAdd("prm").setAttr("id","Content-Type").setText("text/plain");
    cntText = "Object2-k001\r\n";
    cntText += "\r\n";
    cntText += "v002\r\n";
    cntText += " n1\r\n";
    cntText += "  09.03.10 16   Polnyj    7155.25    216.0  32.000  17.5\r\n";
    cntText += "v005\r\n";
    cntText += " n1\r\n";
    cntText += "  09.03.10 16   Polnyj     188.81    350.0   4.000  40.0\r\n";
    cntText += "\r\n";
    cntNode.setText(cntText);
    SYS.Transport.Sockets.out_testHTTP.messIO(req,"HTTP");

    //POST запит із одиничним вмістом
    req = SYS.XMLNode("POST");
    req.setAttr("URI","/WebUser/FlowTec.txt");
    req.childAdd("prm").setAttr("id","Content-Type").setText("text/plain");
    cntText = "Object2-k001\r\n";
    cntText += "\r\n";
    cntText += "v002\r\n";
    cntText += " n1\r\n";
    cntText += "  09.03.10 16   Polnyj    7155.25    216.0  32.000  17.5\r\n";
    cntText += "v005\r\n";
    cntText += " n1\r\n";
    cntText += "  09.03.10 16   Polnyj     188.81    350.0   4.000  40.0\r\n";
    cntText += "\r\n";
    req.setText(cntText);
    SYS.Transport.Sockets.out_testHTTP.messIO(req,"HTTP");

## 4 API користувацького програмування

Вхідна частина об'єкту модуля (SYS.Protocol.HTTP.{In})

- bool setUser( string user ) — змінює користувача пов'язаного із ідентифікатором сеансу автентифікації.
  - user — користувач для зміни.
- bool pgAccess(string URL) — перевіряє доступність сторінки, визначеної у URL.
  - URL — URL сторінки, що перевіряється.
- string pgCreator(string cnt, string rcode = "", string httpattrs = "Content-Type: text/html;charset={SYS}", string htmlHeadEls = "", string forceTmplFile = "") — формує сторінку або ресурс із вмістом cnt, загорнутим у HTTP з результатом rcode, із додатковими атрибутами HTTP httpattrs, додатковим елементом заголовку HTML htmlHeadEls та використанням файлу шаблону forceTmplFile та для мови lang.
  - cnt — вміст сторінки або ресурсу (зображення, XML, CSS, JavaScript, ...);
  - rcode — результуючий код HTTP, на кшталт "200 OK"; порожнє значення вимикає додання HTTP заголовку;
  - httpattrs — додаткові атрибути HTTP, переважно це "Content-Type" із значенням по замовченню "text/html;charset={SYS}"; тільки для "Content-Type: text/html" буде здійснюватися загортання у внутрішній/сервісний, або визначений forceTmplFile, HTML-шаблон;
  - htmlHeadEls — додатковий тег заголовку HTML, переважно це META з "Refresh" для вказаного URL;
  - forceTmplFile — файл прямо визначеного шаблону для перекриття внутрішнього/сервісного або головної сторінки.

Modules/HTTP/uk - GFDL | July 2026 | OpenSCADA 1+r3070