Closed qrkourier closed 2 years ago
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
@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.
@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:
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.
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.
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.
Changes proposed in https://github.com/openziti/ziti-sdk-nodejs/pull/50
fixed in 0.13.2
There's a comment in this app that uses the SDK that says
ref: https://github.com/openziti/ziti-webhook-action/blob/main/index.js#L109
Is this still the case? I don't have the option to strictly define the Ziti service name in my case because I'm using ZEDS which generates a service name based on the name that I provide.