OpenSCADA

Modules/HTTP

English • ‎mRussian • ‎Українська
Module Name Version License Source Languages Platforms Type Author Description
HTTP HTTP-realization 3.9 GPL2 prot_HTTP.so en,uk,ru,de x86,x86_64,ARM Protocol Roman Savochenko
  Maxim Lysenko (2009) — the page initial translation 		Provides support for the HTTP protocol for WWW-based user interfaces.
+ implementation the HEAD request for true support the "HTTP range requests" (function of transition).

Module of the transport protocol HTTP is designed to support the implementation of the network protocol HTTP (Hypertext Transfer Protocol) in OpenSCADA.

HTTP protocol is used to transfer the WWW content. For example, via HTTP the following types of documents are transmitted: html, xhtml, png, javascript, and many others. Support HTTP in OpenSCADA together with the transport Sockets and SSL allows to implement various user functions based on the WWW interface. The module initially implements two main methods of the HTTP protocol "GET", "POST", and currently any HTTP method. The module provides control of the integrity of HTTP-queries and, jointly with Sockets and SSL transport, allows to "collect" whole requests from their fragments, as well as hold of the connection "alive" (Keep-Alive).

For flexible connection of the user interfaces to this module, the modular mechanism within the module itself is used. In the role of modules the modules of the subsystem "User interfaces" are used with the additional information field "SubType", with the value of "WWW".

In the requests for the Web resources the URL(Universal Resource Locator) are commonly used. Hence, the URL is passed as the main parameter via HTTP. The first element of the requested URL is used to identify the module UI. For example, the URL "http://localhost:10002/WebCfg" means requesting to the module "WebCfg" on the host "http://localhost:10002". In the case of an incorrect indication of the module ID, or when you address without identifier of the module at all, the module generates the information dialogue on the entry and the choice of one of the available user interfaces. Example of the dialogue is shown in Figure 1.

Fig.1. Dialogue of the WWW-interface module choice.

The module supports multi-language which one enabled by the dynamic messages translation of OpenSCADA.

The language of the final user interface is determined by and in sequence:

Gotten in the way language used for building interfaces of the module and passes to the WWW sub-modules into the HTTP property "oscd_lang" of the argument "vars" of the generic, "GET" and "POST" functions.

To configure and control this module, you have the configuration page of the OpenSCADA control interface (Fig.3) where you can perform:

Fig.3. The module configuring page.

Contents

1 Authentication

The module supports authentication in OpenSCADA while providing access to the WEB-interface modules (Fig.2).

Fig.2. Authentication dialogue in OpenSCADA.

The authentication by the module is provided by the cookies with the dynamic name and the User ID space, where the cookie name is "oscd_UID" and is used the User ID space in work with the common authentication sessions table, and the cookie name is "oscd_UID_{PrjNm}" in the work without that.

To facilitate with Web-based interfaces, the module provides for automatic login from the specified user's name. Configuring for the automatic login makes by the module settings page (Fig.3). Automatic login performs by matching the address indicated in the column "Address", and on behalf of the user specified in the column "User".

For greater security, you can only identify Web users in the list of users allowed to authenticate.

2 Modules of the WEB-interface

Modules of the user interface (UI) designed to work with the HTTP module, should indicate the information field "SubType" in the value "WWW" and "Auth" field in the value "1", if the module requires an authentication at login. For communication of the HTTP module and the UI modules an advanced communication mechanism is used. This mechanism involves export of interface functions. In this case, the UI modules must export only one generic function for all methods:

meth — method of the request;
uri — local address of the request;
page — page with the answer;
sender — address of the sender;
vars — variables of the request;
user — user, can contain previous user in the second line;
iprt — pointer to an input part object of the protocol.

Or following different functions separately for GET and POST methods:

void HttpGet( const string &uri, string &page, const string &sender, vector<string> &vars, const string &user ); — GET method with the parameters:
uri — local address of the request;
page — page with the answer;
sender — address of the sender;
vars — variables of the request;
user — user, can contain previous user in the second line;
iprt — pointer to an input part object of the protocol.
void HttpPost( const string &uri, string &page, const string &sender, vector<string> &vars, const string &user ); — POST method with the parameters:
uri — local address of the request;
page — page with the answer and with the content of the body of the POST request;
sender — address of the sender;
vars — variables of the request;
user — user, can contain previous user in the second line;
iprt — pointer to an input part object of the protocol.

Then, in the case of the HTTP "GET" request, the function "HTTP_GET" or "HttpGet" will be called, and in the case of the "POST" request, the function "HTTP_POST" or "HttpPost" will be called in the appropriate UI module, or the function "HTTP" for any method.

3 Function of the output requests of the user API

The output request function messIO() operates the exchange of contents of HTTP requests wrapped in XML packets. The query structure has the form: 

<req Host="host" URI="uri">
  <prm id="pId">pVal</prm>
  <cnt name="cName" filename="cFileName">
    <prm id="cpId">cpVal</prm>
    cVal
  </cnt>
  reqVal
</req>
Where:
  • req — request method, supported methods "GET" and "POST".
  • host — http-server address in the format {HostAddr}:{HostIp}. If this field is omitted, then the host address specified in the transport address field is used.
  • uri — resource address at the http server, file or directory.
  • pId, pVal — identifier and value of addition http-parameters. You can set multiply http-parameters setting different prm tags.
  • cName, cFileName, cVal — name, file-name and value of the content-element of the POST-request. You can set multiply content-elements setting different cnt tags.
  • cpId, cpVal — identifier and value of addition content-parameters. You can set multiply content-parameters setting different prm tags;
  • reqVal — single content of the POST request.

The query result is the response structure: 

<req Host="host" URI="uri" err="err" Protocol="prt" RezCod="rCod" RezStr="rStr">
  <prm id="pId">pVal</prm>
  respVal
</req>
Where:
  • req — request method.
  • host — http-server address.
  • uri — resource address.
  • err — error occurring during the request. In the case of a successful request, this field is empty.
  • RezCod, RezStr — query result in the form of code and text.
  • pId, pVal — identifier and value of the addition http-parameter. Http-parameters can be many, defined by the individual prm tags.
  • respVal — content of the response.

Here is the formation of GET and POST requests in the JavaLikeCalc.JavaScript language, as an example of using this function in user procedures: 

//GET request for a HTML-page
req = SYS.XMLNode("GET");
req.setAttr("URI","/");
SYS.Transport.Sockets.out_testHTTP.messIO(req,"HTTP");
test = req.text();

//GET request and saving a file
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 request
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 request with single content
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 User programming API

Input part of the module object (SYS.Protocol.HTTP.{In})

Modules/HTTP/en - GFDLNovember 2024OpenSCADA 1+r2996