Testing WebHooks

When developing server-to-server applications, it is important to be able to test webhooks without leaking sensitive or private information. To avoid having to use 3rd party services, such as webhook.site a new package has been made available containing a service that can be installed on any Neuron®, that allows you to view incoming POST requests in a similar fashion.

Installable Package

The Web-Hook Tester service has been made into a package that can be downloaded and installed on any TAG Neuron. If your Neuron is connected to the TAG Neuron network, you can install the package using the following information:

Package information
Package TAG.WebHookTester.package
Installation key Mb9pim8FTjHBnju2f2ZVNHBRbOG3VHhM7iBn26mgcvc/uwjouWjHEF0OmcC/noKEuZAOWZY6Ka4A4abb4fc2a2596e04f047400e3218dcd2
Repository WebHookTester repository at GitHub

Installing the package via the administrative console (Chat Admin), can be done using the following command:

install nobackup TAG.WebHookTester.package Mb9pim8FTjHBnju2f2ZVNHBRbOG3VHhM7iBn26mgcvc/uwjouWjHEF0OmcC/noKEuZAOWZY6Ka4A4abb4fc2a2596e04f047400e3218dcd2

Starting service

The WebHook tester service appears in the administrative portal, in the Software section:

WebHook Tester Service Button
WebHook Tester Service Button

Pressing it, opens the following page: https://lab.tagroot.io/WebHookTester/Show.md

WebHook Tester Main Page
WebHook Tester Main Page

Note: This page does not require client authentication, and can be used anonymously.

Note 2: You can also use the script prompt to make custom POST calls to the page. This requires elevated privileges however, and cannot be done anonymously.

Creating a Page

Enter an ID and press the Start button to create a new page you can POST to. Since the service can be accessible by anyone, use an ID that is difficult to guess, if you do not want others to get easy access to the information. Press the Randomize button to create a random ID. You can customize the random ID to remember the purpose of the page, if you have multiple pages open.

Create WebHook Test Page
Create WebHook Test Page

Test Page

When you press the Start button, a new page is opened. It contains instructions how you can POST to the page:

WebHook Test Page
WebHook Test Page

Use the URL presented to POST to the page. If you want to test a back-end service integration, this is the URL you provide as a webhook callback URL. Any POST made to this URL will be displayed on the page.

Note: Nothing is saved or persisted on the page. The page does not remember previous POSTs, so if you refresh the page you loose the information on the page.

Note 2: Make sure to differentiate between the URL of the page (which points to a resource with extension .md) and the URL to POST to (which points to a resource with extension .ws).

Incoming POSTs

As soon as an incoming POST is made, it is displayed on the page as follows. It displays the time of the event, any HTTP headers in the request, together with a textual representation of the payload (if content is text-based), as well as the binary payload, BASE64-encoded. Each POST is presented in its own SECTION tag on the page.

WebHook POST Example
WebHook POST Example

Responses

The response to a POST call to the resource will be a JSON object with one property called Forwarded, which indicate the number of pages the information was forwarded to. If this number is 0, the page has closed or lost contact with the Neuron. Example:

{
	"Forwarded":1
}

Tunneling POST request over XMPP

As the Neuron is connected to the XMPP network as well, since it is hosted on the IoT Gateway, the POST request can be tunneled over the XMPP network using the httpx:// URI scheme. This permits you to do callbacks to local development machines, or machines not accessible via the Internet.

To achieve this, you need to perform the call from another instance hosted on the IoT Gateway. It can be the IoT Gateway itself, Lil’Sis’ or another instance of the TAG Neuron, including a development version on a local machine. You replace the https scheme in the URI with the httpx URI scheme, and replace the host with the JID of the recipient. For the call to succeed, the sender and receiver need to be friends, i.e. have approved presence subscriptions, for the call over XMPP to be possible.

This can be easily tested using the script prompt:

WebHook Tester httpx Example
WebHook Tester httpx Example

Note: Any software using the Waher.Content Internet Content-Type abstraction, and the InternetContent content access methods, together with the Waher.Networking.XMPP.HTTPX library (containing the httpx URI scheme definition) will automatically support httpx URIs.

Note 2: Since the QuickLogin API and RemoteLogin API are both hosted on the TAG Neuron®, you can register httpx callback URIs with these APIs. This makes it possible to host the recipient service behind a firewall, as long as it supports the HTTP over XMPP protocol

#new, #features, #package, #repository, #neuron, #service


Modbus-XMPP Bridge

The IoTBridgeModbus repository provides an IoT bridge between devices connected to Modbus, for use in closed intra-networks or enterprise networks, and the harmonized XMPP-based Neuro-Foundation network, for open and secure cross-domain interoperation on the Internet.

Bridge topology
Bridge topology

To run the bridge, you need access to both a Modbus gateway, and an XMPP broker, that supports the Neuro-Foundation extensions. You can use the TAG Neuron for XMPP.

Running and configuring the bridge

The code is written using .NET Standard, and compiled to a .NET Core console application that can be run on most operating systems. Basic configuration is performed using the console interface during the first execution, and persisted. You can also provide the corresponding configuration using environment variables, making it possible to run the bridge as a container. If an environmental variable is missing, the user will be prompted to input the value on the console.

Environmental Variable Type Description
XMPP_HOST String XMPP Host name
XMPP_PORT Integer Port number to use when connecting to XMPP (default is 5222)
XMPP_USERNAME String User name to use when connecting to XMPP.
XMPP_PASSWORD String Password (or hashed password) to use when connecting to XMPP. Empty string means a random password will be generated.
XMPP_PASSWORDHASHMETHOD String Algorithm or method used for password. Empty string means the password is provided in the clear.
XMPP_APIKEY String API Key. If provided together with secret, allows the application to create a new account.
XMPP_APISECRET String API Secret. If provided together with key, allows the application to create a new account.
MODBUS_HOST String Modbus Gateway Host name
MODBUS_TLS String If TLS encryption is to be used when connecting to the Modbus gateway.
MODBUS_PORT String Port number to use when connecting to the Modbus gateway (default is 502).
REGISTRY_COUNTRY String Country where the bridge is installed.
REGISTRY_REGION String Region where the bridge is installed.
REGISTRY_CITY String City where the bridge is installed.
REGISTRY_AREA String Area where the bridge is installed.
REGISTRY_SRTEET String Street where the bridge is installed.
REGISTRY_STREETNR String Street number where the bridge is installed.
REGISTRY_BUILDING String Building where the bridge is installed.
REGISTRY_APARTMENT String Apartment where the bridge is installed.
REGISTRY_ROOM String Room where the bridge is installed.
REGISTRY_NAME String Name associated with bridge.
REGISTRY_LOCATION Boolean If location has been completed. (This means, any location-specific environment variables not provided, will be interpreted as intensionally left blank, and user will not be prompted to input values for them.

Claiming ownership of bridge

Once the bridge has been configured, it will generate an iotdisco URI, and save it to its programd data folder. It will also create a file with extension .url, containing a shortcut with the iotdisco URI inside. A .png file with a QR code will also be generated. All three files contain information about the bridge, and allows the owner to claim ownership of it. This can be done by using the Neuro-Access App. This app is also downloadable for Android and iOS. You scan the QR code (or enter it manually), and claim the device. Once the device is claimed by you, you will receive notifications when someone wants to access the deice. They will only be able to access it with the owner’s permission. For more information, see:

Configuring the bridge

The bridge can be configured in detail by a client that implements the concentrator interface. Concentrators consist of data sources, each containing tree structures of nodes. Nodes may be partitioned into partitions, which permits the nesting of subsystems seamlessly into container systems. Each node can be of different types, and have different properties and underlying functionality. They can each implement then sensor interface and actuator interface.

You can use the Simple IoT Client to configure concentrators and their nodes in detail. An initial setup is done using the initial configuration of the bridge. The client is also available in the IoTGateway repository, in the Clients folder.

Node Types

The bridge includes several different node types that can be used to configure its operation:

  • The Modbus Gateway maintains a connection to a Modbus Gateway using TCP/IP, and converts requests into binary Modbus TCP/IP communication.

  • The XMPP Broker maintains a connection to an XMPP Broker. It allows the bridge to connect to other entities on the federated network and communicate with them. It supports communication with remote standalone sensors and actuators, as well as remote concentrators embedding devices into data sources and nodes. Such concentrators can be bridges to other protocols and networks.

    Note: The bridge has a client-to-server connection by default, setup during initial configuration. Through this connection, the bridge acts as a concentrator. Through the use of XMPP Broker nodes you can setup additional XMPP connections to other brokers. In these cases the bridge will only act as a client, to connect to remove devices for the purposes of interacting with them.

  • IP Host nodes allow you to monitor network hosts accessible from the bridge.

  • Script nodes allow you to create nodes with custom script logic. They can be used to interface bespoke devices in the network accessible from the bridge, for example.

  • Virtual nodes are placeholders where external logic (or script logic) can aggregate information in a way that makes them accessible by others in the federated network.

#new, #repository, #iot, #modbus, #xmpp, #bridge


MQTT-XMPP Bridge

The IoTBridgeMqtt repository provides an IoT bridge between devices connected to MQTT, for use in closed intra-networks or enterprise networks, and the harmonized XMPP-based Neuro-Foundation network, for open and secure cross-domain interoperation on the Internet.

Bridge topology
Bridge topology

To run the bridge, you need access to both an MQTT broker, and an XMPP broker, that supports the Neuro-Foundation extensions. You can use the Mosquitto broker for MQTT, and the TAG Neuron for XMPP.

Running and configuring the bridge

The code is written using .NET Standard, and compiled to a .NET Core console application that can be run on most operating systems. Basic configuration is performed using the console interface during the first execution, and persisted. You can also provide the corresponding configuration using environment variables, making it possible to run the bridge as a container. If an environmental variable is missing, the user will be prompted to input the value on the console.

Environmental Variable Type Description
XMPP_HOST String XMPP Host name
XMPP_PORT Integer Port number to use when connecting to XMPP (default is 5222)
XMPP_USERNAME String User name to use when connecting to XMPP.
XMPP_PASSWORD String Password (or hashed password) to use when connecting to XMPP. Empty string means a random password will be generated.
XMPP_PASSWORDHASHMETHOD String Algorithm or method used for password. Empty string means the password is provided in the clear.
XMPP_APIKEY String API Key. If provided together with secret, allows the application to create a new account.
XMPP_APISECRET String API Secret. If provided together with key, allows the application to create a new account.
MQTT_HOST String MQTT Host name
MQTT_TLS String If TLS encryption is to be used when connecting to the MQTT broker.
MQTT_PORT String Port number to use when connecting to MQTT (default is 1883 for unencrypted MQTT and 8883 for encrypted MQTT).
MQTT_USERNAME String User name to use when connecting to MQTT. Can be empty if no user credentials are provided.
MQTT_PASSWORD String Password to use when connecting to XMPP. Can be empty if no user credentials are provided.
REGISTRY_COUNTRY String Country where the bridge is installed.
REGISTRY_REGION String Region where the bridge is installed.
REGISTRY_CITY String City where the bridge is installed.
REGISTRY_AREA String Area where the bridge is installed.
REGISTRY_SRTEET String Street where the bridge is installed.
REGISTRY_STREETNR String Street number where the bridge is installed.
REGISTRY_BUILDING String Building where the bridge is installed.
REGISTRY_APARTMENT String Apartment where the bridge is installed.
REGISTRY_ROOM String Room where the bridge is installed.
REGISTRY_NAME String Name associated with bridge.
REGISTRY_LOCATION Boolean If location has been completed. (This means, any location-specific environment variables not provided, will be interpreted as intensionally left blank, and user will not be prompted to input values for them.

Claiming ownership of bridge

Once the bridge has been configured, it will generate an iotdisco URI, and save it to its programd data folder. It will also create a file with extension .url, containing a shortcut with the iotdisco URI inside. A .png file with a QR code will also be generated. All three files contain information about the bridge, and allows the owner to claim ownership of it. This can be done by using the Neuro-Access App. This app is also downloadable for Android and iOS. You scan the QR code (or enter it manually), and claim the device. Once the device is claimed by you, you will receive notifications when someone wants to access the deice. They will only be able to access it with the owner’s permission. For more information, see:

Configuring the bridge

The bridge can be configured in detail by a client that implements the concentrator interface. Concentrators consist of data sources, each containing tree structures of nodes. Nodes may be partitioned into partitions, which permits the nesting of subsystems seamlessly into container systems. Each node can be of different types, and have different properties and underlying functionality. They can each implement then sensor interface and actuator interface.

You can use the Simple IoT Client to configure concentrators and their nodes in detail. An initial setup is done using the initial configuration of the bridge. The client is also available in the IoTGateway repository, in the Clients folder.

Node Types

The bridge includes several different node types that can be used to configure its operation:

  • The MQTT Broker maintains a connection to an MQTT Broker, and allows the bridge to subcribe to content published on topics, as well as publish content to topics on the broker. The topic hierarchy will be modelled using MQTT Topic nodes, or derivatives. Common data types are recognized and parsed. You can read each topic individually, or a parent topic, and receive information from all child topics, as field values.

  • The XMPP Broker maintains a connection to an XMPP Broker. It allows the bridge to connect to other entities on the federated network and communicate with them. It supports communication with remote standalone sensors and actuators, as well as remote concentrators embedding devices into data sources and nodes. Such concentrators can be bridges to other protocols and networks.

    Note: The bridge has a client-to-server connection by default, setup during initial configuration. Through this connection, the bridge acts as a concentrator. Through the use of XMPP Broker nodes you can setup additional XMPP connections to other brokers. In these cases the bridge will only act as a client, to connect to remove devices for the purposes of interacting with them.

  • IEEE 1451 nodes are derivatives of MQTT nodes, and implement support for the IEEE 1451 family of standards, of which IEEE 1451.1.6 manages communication over MQTT.

  • IP Host nodes allow you to monitor network hosts accessible from the bridge.

  • Script nodes allow you to create nodes with custom script logic. They can be used to interface bespoke devices in the network accessible from the bridge, for example.

  • Virtual nodes are placeholders where external logic (or script logic) can aggregate information in a way that makes them accessible by others in the federated network.

#new, #repository, #iot, #mqtt, #xmpp, #bridge


Integrating Serpro into Neuron®-based services

You can use Serpro in Neuron®-based services, by installing the TAG.Serpro.package, available in the Packages page in the Admin menu, and use the examples provided in your own services. Serpro provides an identity application authenticator, that can be used to automate the approval of identity applications on the Neuron® where it is installed. You will need to provide a key when installing. Use the following public key:

Some more information
Package TAG.Serpro.package
Installation key 0WMoLBoAObn+SPgJ6Zfl6iJTxhnW8050o0sHba37z+51BUHjRm3dyL08qqQ+n4iTFDL6PYVOWeAA4bda1f2a8fb0d70921434eed848e39e7
Configuring Service /Serpro/Settings.md on the Neuron® on which the service is installed.
More information <https://github.com/Trust-Anchor-Group/NeuronSerpro>

#features, #id, #kyc, #neuron, #api, #repository, #new


Neuro Exchange Theme

The Neuro Exchange theme has been made into a package that can be downloaded and installed on any TAG Neuron. You can configure to use this theme in the Theme menu accessible from the admin dashboard.

Package information
Package TAG.NeuroExchange.Theme
Installation key BGVWw9FYGj6+mY8nxScZgoKRC8SiV80mWJhHXfUZL3ASrwZSab5PdEwmyfwpJVUEWEMNST4HWayA1640d45c2eae16ecf48e883c75dd25f7
More Information https://github.com/Trust-Anchor-Group/TAG.NeuroExchange.Theme

#package, #theme, #neuron, #repository


Posts tagged #repository

No more posts with the given tag could be found. You can go back to the main view by selecting Home in the menu above.