SDK requires Ziti service name == url.hostname ? about ziti-sdk-nodejs

[qrkourier]

I stumbled upon the comment about the service name matching because the ziti-webhook-action app hangs after successfully initializing the Ziti connection.

[        0.000] INFO	ziti-sdk-nodejs/src/ziti-add-on.c:59 Init(): Ziti NodeJS SDK version 
	Version:	0.9.2
	Build Date:	Thu Jun 16 21:02:12 UTC 2022
	Git Branch:	main
	Git SHA:	314a7cf
	OS:     	unknown
	Arch:   	x86_64
	@314a7cf(main) starting at (2022-09-14T19:28:14.195)
Going async...
Webhook URL: http://webhookz.ziti/post
[        0.158]    INFO ziti-sdk:ziti.c:397 ziti_init_async() ztx[0] Ziti C SDK version 0.28.7-148 @ce91b21(HEAD) starting at (2022-09-14T19:28:14.237)
[        0.158]    INFO ziti-sdk:ziti.c:398 ziti_init_async() ztx[0] using uv_mbed[v0.14.7], tls[OpenSSL 1.1.1l  24 Aug 2021]
[        0.158]    INFO ziti-sdk:ziti.c:399 ziti_init_async() ztx[0] Loading from config[./zid.json] controller[https://7ce7e424-6a92-4ff2-9459-ebbba32346fa.production.netfoundry.io:443]
[        0.158]    INFO ziti-sdk:ziti_ctrl.c:375 ziti_ctrl_init() ctrl[7ce7e424-6a92-4ff2-9459-ebbba32346fa.production.netfoundry.io] ziti controller client initialized
[        0.158]    INFO ziti-sdk:ziti.c:792 ziti_re_auth_with_cb() ztx[0] starting to re-auth with ctlr[https://7ce7e424-6a92-4ff2-9459-ebbba32346fa.production.netfoundry.io:443] api_session_status[0] api_session_expired[TRUE]
[        0.241]    INFO ziti-sdk:ziti.c:1438 version_cb() ztx[0] connected to controller https://7ce7e424-6a92-4ff2-9459-ebbba32346fa.production.netfoundry.io:443 version v0.26.5(e5d4b19e3568 2022-08-17T14:01:21Z)
[        0.267]    INFO ziti-sdk:ziti.c:1328 ziti_set_api_session() ztx[0] api session set, setting api_session_timer to 1740s
[        0.150] INFO	ziti-sdk-nodejs/src/ziti_init.c:125 on_ziti_event(): controller version = v0.26.5(e5d4b19e3568)[2022-08-17T14:01:21Z]
[        0.150] INFO	ziti-sdk-nodejs/src/ziti_init.c:126 on_ziti_event(): identity = <github1 webhookz1 Z29vZ2xlLW9hdXRoMnwxMTYwMTQzMjA2MDgwNTM4ODkyOTQ=>[FJPKGpoyD]@https://7ce7e424-6a92-4ff2-9459-ebbba32346fa.production.netfoundry.io:443
[        0.307]    INFO ziti-sdk:channel.c:219 new_ziti_channel() ch[0] (Zeds Fabric Router@tls://193.122.155.132:443) new channel for ztx[0] identity[github1 webhookz1 Z29vZ2xlLW9hdXRoMnwxMTYwMTQzMjA2MDgwNTM4ODkyOTQ=]
[        0.191] INFO	ziti-sdk-nodejs/src/ziti_init.c:173 on_ziti_event(): edge router Zeds Fabric Router@tls://193.122.155.132:443 was added
[        0.307]    INFO ziti-sdk:channel.c:731 reconnect_channel() ch[0] reconnecting NOW
[        0.307]    INFO ziti-sdk:channel.c:219 new_ziti_channel() ch[1] (Ziti Fabric Router OCI@tls://129.80.152.107:443) new channel for ztx[0] identity[github1 webhookz1 Z29vZ2xlLW9hdXRoMnwxMTYwMTQzMjA2MDgwNTM4ODkyOTQ=]
[        0.191] INFO	ziti-sdk-nodejs/src/ziti_init.c:173 on_ziti_event(): edge router Ziti Fabric Router OCI@tls://129.80.152.107:443 was added
[        0.307]    INFO ziti-sdk:channel.c:731 reconnect_channel() ch[1] reconnecting NOW
[        0.349]    INFO ziti-sdk:channel.c:629 hello_reply_cb() ch[0] connected. EdgeRouter version: v0.26.5|e5d4b19e3568|2022-08-17T14:01:21Z|linux|amd64
[        0.232] INFO	ziti-sdk-nodejs/src/ziti_init.c:161 on_ziti_event(): ziti connected to edge router Zeds Fabric Router@tls://193.122.155.132:443
version = v0.26.5|e5d4b19e3568|2022-08-17T14:01:21Z|linux|amd64
[        0.359]    INFO ziti-sdk:channel.c:629 hello_reply_cb() ch[1] connected. EdgeRouter version: v0.26.5|e5d4b19e3568|2022-08-17T14:01:21Z|linux|amd64
[        0.242] INFO	ziti-sdk-nodejs/src/ziti_init.c:161 on_ziti_event(): ziti connected to edge router Ziti Fabric Router OCI@tls://129.80.152.107:443
version = v0.26.5|e5d4b19e3568|2022-08-17T14:01:21Z|linux|amd64
[       20.268]    INFO ziti-sdk:posture.c:197 ziti_send_posture_data() ztx[0] first run or potential controller restart detected

[rentallect]

@qrkourier I believe this issue has been resolved in version 0.13.0. When you get a chance, try it out and let me know if you still experience problems.

[qrkourier]

@rentallect I see this example in the main readme:

ziti.httpRequest(
  'myDarkWebService', 
  'GET', 
  '/',              // path
  ['Accept: application/json' ], // headers
  undefined,        // optional on_req cb 
  undefined,        // optional on_req_data cb
  on_resp_data      // optional on_resp_data cb
);

Is it accurate that myDarkWebService may be either of:

• the Ziti service name, or
• the url.origin e.g. https://example.org:443

and that the path param should be the url.pathname+url.search i.e. the URL path part concatenated with query params e.g. /path/to/api?foo=bar&this=that?

With that usage I got this error, and so the SDK seems to be failing to resolve the Ziti service by intercept address.

(1718)[        0.460]   ERROR ziti-sdk:ziti_src.c:95 ziti_src_connect() no service for address[tcp:webhookz.ziti:80]

EDIT: another troubleshooting step I took was to send the Ziti service name as first positional instead of the HTTP origin. I got an error from the C function when it failed to resolve the name.

Error: zitiHttpRequest failed: Error: Unknown serviceName

I should mention that I have previously connected to the same service with the same identity and so have no reason to suspect this is an authorization or configuration problem in the Ziti network.

[qrkourier]

I verified that my service's intercept.v1 config is:

{
  "addresses": [
    "webhookz.ziti"
  ],
  "protocols": [
    "tcp"
  ],
  "portRanges": [
    {
      "low": 80,
      "high": 80
    }
  ]
}

And I am able to get the expected response from the service via a tunneler on my workstation like this:

http POST http://webhookz.ziti/post this=that

I'm using env ZITI_LOG=4 to get DEBUG logging from the C SDK and so I am able to verify that my Node app has a Ziti identity context for the correct Ziti network by comparing the URL of the controller.

[qrkourier]

I think httpRequest calls this C function: https://github.com/openziti/ziti-sdk-nodejs/blob/main/src/Ziti_https_request.c#L740 which has comments clarifying that the first positional may be service name or URL, but I think "HTTP origin" might be more accurate since the path part is passed separately and becomes addon_data->path which is composed as the httpsReq object, if I'm reading this correctly.

[qrkourier]

Changes proposed in #50

[rentallect]

fixed in 0.13.2