Skip to main content

Adding a basic HTTPS connection

What is a basic HTTPS connection?

Basic HTTPS connections, also known as NS-AS Tunnel Interface, provide a direct bidirectional connection between the Network Server (NS) and third-party Application Servers (AS) using HTTPS protocol.

For security purposes, downlink messages are accepted only if an encrypted token is included in the POST. Device payloads are exchanged in an encoded format without the support of payload drivers.

This connection type does not support message queuing services: when the AS is temporarily unavailable or overloaded, the uplink messages will be lost. The AS may also be temporarily throttled by software fuses if it cannot keep up with uplinks.

To learn more about basic HTTPS connections and NS-AS Tunnel Interface, see ThingPark Enterprise LRC-AS Tunnel Interface Developer Guide for LoRaWAN®.

Adding a basic HTTPS connection

  1. Select Connections, and click ADD CONNECTION on the Connections page, or from Dashboard, go to the CONNECTIONS widget, and click.

  2. Click the Basic HTTPS type of connection.

  3. Enter your connection information:

    • Name

    • (Optional) Domains: If the permission segregation based on domains has been enabled by an administrator user, you may associate your connection with domains to restrict its visibility. See About domains.

      • If no domains are set, the connection is cross-domain and visible to all users.
      • If your user account has domain restrictions, the associated domains must match your domain restrictions without any domain prefix (only full domains can be assigned to resources).
    • (Optional) Additional information: Any useful information (for instance, administrative) that is related to the connection.

  4. Configure the tunnel interface authentication:

    • In the Key area, click Copy and save the key that you must share with the HTTPS application server.

      info

      This system-generated security key provides an application-level signature to the uplink messages sent from ThingPark to the application server (AS), as well as the downlink messages sent from the AS to ThingPark. This is particularly needed for downlink paths, to ensure that only an AS having this key can send downlink messages to your devices. To learn more about the use of this key,

      see ThingPark Enterprise LRC-AS Tunnel Interface Developer Guide for LoRaWAN®.

    • (Optional) Maximum timestamp deviation: To enhance security against replay attacks, enter the tolerance of the downlink timestamp deviation in seconds.

  5. Configure the destinations:

    • URLs: Enter the URL or URLs of the application server where ThingPark will send uplink messages. Note: URLs are processed in the list order. The URL format must follow RFC-3986.

    • Strategy: Only applies if several URLs are declared in URLs.

      • Sequential: Attempts the routing in the defined order of the URLs and stops routing to the following URLs once a 2xx response (successful) is received from the last attempted URL. Maximum 5 URLs.

      • Blast: Always route to all the URLs in the defined order. Maximum 3 URLs.

      advanced

      If you want to discriminate uplink messages without LoRaWAN payload from uplink messages with LoRaWAN payload, and distribute the latter according to their FPort:

      • Click ENABLE PORT-BASED ROUTING.
      • Configure Port(s), URLs, and Strategy for each route you create. Set one or more eligible ports as a list (for instance, 1,5), or a range of ports (for instance, 1-5). Use only * for the last route to wildcard all the remaining ports. A given port cannot be set on different routes. Note: Uplink messages without LoRaWAN payloads are always sent to the first route only. You can reorder routes as needed. Creating only one route is like not enabling port-based routing.
  6. Configure the HTTP requests:

    • (Optional) Custom HTTP Headers: To meet the application server's needs, you can define up to 5 custom HTTP headers in uplink messages for each basic HTTP connection. Each custom HTTP header is statically defined as a string (for instance, "Authorization: Bearer AbCdEf123456").

      • In Custom HTTP Headers, click +.
      • Each header is composed of two fields to be defined following RFC 7230:
        • Header Name: "Accept", "Host", "User-Agent", "Content-Length", "Content-Type", "Expect" and "Proxy-Authorization" are forbidden. A given header name can be configured only once (case insensitive).
        • Header Value
        • The maximum length of an HTTP header (name + value) is 510 characters.
      info

      You can define explicitly the "Authorization" header as a custom HTTP header, but it can also be implicitly generated by the network server when the destination URL contains a login/password (for instance, http://user:pwd@application.com). When both are defined, priority is given to the login/password defined in URLs in Configure the destinations (step 5).

    • Content Type: The type of encoding used to report device data to your application. Use the same content type as the application server:

      • XML

      • JSON. Example:

        {
        "DevEUI":"78A8952D2E2992C5",
        "FPort":2,
        "LrrRSSI":-60.000000
        }
      • JSON untyped: JSON document where all values, including numeric values, are reported as strings. Example:

        {
        "DevEUI":"78A8952D2E2992C5",
        "FPort":"2",
        "LrrRSSI":"-60.000000"
        }
  7. Click ADD.