Hello,
I noticed I have trouble to forward an url from my source to a localhost endpoint containing :.

I think this is the root cause:

I believe some extra char should be allowed, I'm not a pro reading RFCs 😀 (https://datatracker.ietf.org/doc/html/rfc1738#section-2.2) but at least the percent sign % should be allowed in order to use special char in paths. In my example it should be %3A

I don't know Go but I added (for the test) the % as an accepted char for the regex and it works. (I mean %3A correctly redirect to my local webhook handler that takes :.

I think a better solution is to accept \%[A-F0-9]{2} or something, but same, I'm not a pro :)

Workaround: edit the url from the webapp works.

postprocessJsonResponse is used in several places with the function signature returning and interface and an error but we are passing pointers to the function and never checking the errors.

We should refactor to ensure errors are checked.

We are not currently building an ARM version for linux.

I'm getting a segfault when I attempt to use a source and a connection through the CLI. The connection errors whenever I use either a valid or invalid connection. I get no errors when only specifying the source. Link to line segfaulting here

hookdeck listen 8080 test testconn
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x2 addr=0x8 pc=0x10040af84]

goroutine 1 [running]:
github.com/hookdeck/hookdeck-cli/pkg/listen.getConnections(0x140001dedc0, 0x14000244960, {0x16fdbe85b, 0x8})
	/Users/runner/work/hookdeck-cli/hookdeck-cli/pkg/listen/connection.go:41 +0x2a4
github.com/hookdeck/hookdeck-cli/pkg/listen.Listen(0x140001483f0, {0x16fdbe855, 0x5}, {0x16fdbe85b, 0x8}, {0x64?}, 0x1008a7180)
	/Users/runner/work/hookdeck-cli/hookdeck-cli/pkg/listen/listen.go:54 +0xa8
github.com/hookdeck/hookdeck-cli/pkg/cmd.(*listenCmd).runListenCmd(0x1400015e820, 0x1001d2710?, {0x140001d0f90, 0x140001b3bb8?, 0x0?})
	/Users/runner/work/hookdeck-cli/hookdeck-cli/pkg/cmd/listen.go:115 +0x194
github.com/spf13/cobra.(*Command).execute(0x140001e0000, {0x140001d0f60, 0x3, 0x3})
	/Users/runner/go/pkg/mod/github.com/spf13/[email protected]/command.go:842 +0x4c4
github.com/spf13/cobra.(*Command).ExecuteC(0x10089dec0)
	/Users/runner/go/pkg/mod/github.com/spf13/[email protected]/command.go:950 +0x34c
github.com/spf13/cobra.(*Command).Execute(...)
	/Users/runner/go/pkg/mod/github.com/spf13/[email protected]/command.go:887
github.com/hookdeck/hookdeck-cli/pkg/cmd.Execute()
	/Users/runner/work/hookdeck-cli/hookdeck-cli/pkg/cmd/root.go:46 +0x34
main.main()
	/Users/runner/work/hookdeck-cli/hookdeck-cli/main.go:21 +0x20```

How

1. Add the * select to the listen command. Right now you can do hookdeck listen 9001 shopify which starts the CLI without a source select prompt for the source specified. With hookdeck listen 9001 * we could let you select all sources
2. Support comma delimited source selector. Same as #1 but hookdeck listen 9001 shopify,stripe to start on a set of sources
3. On hookdeck listen 9001 the source select prompt should have a “all” option which has the same behavior as *

4. When the CLI starts, the terminal printout should support multiple sources & URL. The terminal should probably only print the first ~10. The connection name also needs to display the full name with the source prefix like shopify -> out-of-stock

The backend should already support this as only a set of connection IDs are expected

Caveat & questions

They * could cause problem if there are thousands of sources, should we put a upper bound of the first 100 as a limitation?

We have a bad tag version for v0.34 ... should be v0.3.4 and is messing up asdf.

Will likely need to remove the tag and recreate correctly.

When using hookdeck cli via docker how do I persist a login? After running the command and successfully logging in the next run of the docker command creates a guest account. I'm assuming mounting a volume would do the trick, but I haven't been able to determine where credentials are stored.

See #84 (comment)

Hi there, I've been tinkering with some DX around local config and discovered some undesirable behaviors. I made a few videos here to showcase these issues in hope we can discuss and improve the CLI.

The first video is on some issues with projects and confusing messages when there's a local configuration. There's also an issue during the logout flow as well: https://share.cleanshot.com/CW0f4lQQ

The second video focuses on project switching behavior: https://share.cleanshot.com/DYKVjc5P

Let me know what you think and happy to discuss or clarify things further.

The CLI and Dashboard connection state sometimes desynchronized where the Dashboard will show Disconnected and the CLI will show "Ready...". When that occurs no events are received on the CLI although it incorrectly is shown as ready.

At this time there is no specific reproduction step, last seen on an Intel Macbook.

It would be great to have a couple options for working with TLS connections locally:

• --ssl to force using a TLS client (autodetect from URL scheme or port 443)
• -k --insecure (matching curl's flags) on listen to enable InsecureSkipVerify
• --cacert <file> (matching curl) to specify a PEM format certificate to use as the root cert when working with self signed certs

You also imagine r+1 r+2 r+3 to retry second the last, third to last, etc.

Steps to reproduce:

• Download latest docker image docker pull hookdeck/hookdeck-cli
• Attempt to connect with a guest account - docker run -it hookdeck/hookdeck-cli listen 3000

Initialization succeeds, guest account & source are created, but CLI remains stuck in Getting Ready state, and never connects. Preliminary debugging shows that the process hangs here:

I using hookdeck cli with docker and Im trying to run it as another user than root.
To accomplish that Im trying to use --config flag of hookdeck cli. No matter what I try, the flag seems to be ignored.

I put the config file in /tmp/.config/hookdeck/config.toml
and try to start hookdeck cli with
hookdeck listen homeassistant-service:8080 automate --config /tmp/.config/hookdeck/config.toml

I always get
"Not connected with any account. Creating a guest account..."

I have a Rails app running locally. It uses Action Mailbox which receives webhooks from mail systems such as Postmark. Action Mailbox requires incoming webhooks to use a URL with basic authentication like this:

https://actionmailbox:[email protected]/rails/action_mailbox/postmark/inbound_emails

When running locally, the URL needs to be:

http://actionmailbox:[email protected]:3000/rails/action_mailbox/postmark/inbound_emails

As far as I can tell the Hookdeck CLI does not support this. Please could you add it?

The Stripe CLI supports triggering test webhooks from the CLI.

Hookdeck supports bookmarks, an underused feature. Is there a way we could add a command such as hookdeck trigger [bookmark-name] and support triggering events in a similar way to the Stripe CLI?

This is similar to the lines of #98

Occasional crash related to establishing the WebSocket connection

We store "api key" in the config but reference "cli key" in the env var and flag names. In the web app we call it "api key".

We should change everything to "api key" to match the product naming convention.

Issue:
I followed this article https://hookdeck.com/webhooks/platforms/tutorial-github-webhooks#get-the-webhook-url to setup Hookdeck CLI and to receive HTTP POST request on the endpoint configured in the Node app that is linked to in the tutorial.
After completing all the steps and upon creating an issue in my Github repo for which the webhook is created, I got the following error in the CLI: 2022-04-18 19:11:41 [ERROR] Failed to POST: Post "http://localhost:1337/log-github-webhook": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

Also, the node app shows this TypeError: UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'timestamp' of undefined

Running the command:

hookdeck listen 3030

Would generate a source name. For example, source_<random_letters_numbers>

Scoop won't create a symlink properly when there are special characters in the Windows directory that it's being installed in:

PS C:\Users\Test&test> scoop bucket add hookdeck https://github.com/hookdeck/scoop-hookdeck-cli.git
Checking repo... ok
The hookdeck bucket was added successfully.
PS C:\Users\Test&test> scoop install hookdeck
Installing 'hookdeck' (0.4.4) [64bit]
hookdeck_0.4.4_windows_x86_64.zip (3.5 MB) [==================================================================] 100%
Checking hash of hookdeck_0.4.4_windows_x86_64.zip ... ok.
Extracting hookdeck_0.4.4_windows_x86_64.zip ... done.
Linking ~\scoop\apps\hookdeck\current => ~\scoop\apps\hookdeck\0.4.4
The syntax of the command is incorrect.
Creates a symbolic link.
MKLINK [[/D] | [/H] | [/J]] Link Target
        /D      Creates a directory symbolic link.  Default is a file
                symbolic link.
        /H      Creates a hard link instead of a symbolic link.
        /J      Creates a Directory Junction.
        Link    Specifies the new symbolic link name.
        Target  Specifies the path (relative or absolute) that the new link
                refers to.
The system cannot find the path specified.
The system cannot find the path specified.
Creating shim for 'hookdeck'.
Can't shim 'hookdeck.exe': File doesn't exist.

Currently the help output for the listen command is:

$ hookdeck listen -h
Forward webhooks for a source to your local server

Usage:
  hookdeck listen [flags]

Flags:
  -h, --help   help for listen

Global Flags:
      --cli-key string        Your CLI key to use for the command
      --color string          turn on/off color output (on, off, auto)
      --config string         config file (default is $HOME/.config/hookdeck/config.toml)
      --device-name string    device name
      --log-level string      log level (debug, info, warn, error) (default "info")
  -p, --project-name string   the project name to read from for config (default "default")

If you run listen with no arguments:

$ hookdeck listen
Requires a port or forwarding URL to foward the webhooks to

We should change the description to include a reference to the required arguments as examples

hookdeck listen [flags] <hostname>[:port]

I have been having a problem with hookdeck login for some time now.
No matter from which platform I log in (Ubuntu / MacOS) I get the following error message when logging in:

hookdeck login
Press Enter to open the browser (^C to quit)
⣟ Waiting for confirmation... unexpected http status code: 429 Too Many Requests

After about 10-20 seconds the error message appears, even if I do nothing in the browser. The guest login works!

What also does not work, the API login mode (hookdeck login -i). I get every time the error message that the API-Key is not correct. I have also already generated new API keys.

Furthermore, I have also already disabled the local firewall, unfortunately also unsuccessfully.

The error appears under (hookdeck 0.5, 0.6.6, 0.6.7) and Ubuntu 22.04.2 LTS / MacOS Ventura 13.3.1

Add a ARM Docker build to .goreleaser/linux.yml for Apple Silicon Macs compatibility.

Running the following will prompt for a path for the CLI:

hookdeck listen 3030 {SOURCE_NAME} 
? What path should the events be forwarded to (ie: /webhooks)?

However, after this point, if you want to change the path, you need to go to the dashboard and edit from the UI.

Can we add support for setting the CLI path on the original request and changing the "CLI path" for a Destination from the CLI?

There's a great discussion and some good work gone into #68 as an experiment for adding broader CRUD support and we ultimately decided against it (for now).

However, this feels like a common sense feature to support.

Options I can think of:

1. Add a command that supports modifying the CLI path of a source. It would need to check the provided source was of type CLI. We may also then want to allow sources to be listed to help with discoverability. That would need to show the source name, type, and CLI path if the type was CLI path.
2. Add a keypress handler when the CLI is running that allows the path of the running process to be edited. This removes the need for a new command as you just use the current context. However, this is complicated by the support for listening on multiple sources (#84).
3. #87 (comment)

@alexluong WDYT?

The CLI should be able to listen to multiple sources, and with the * listen to all sources

Example: hookdeck listen 9000 * listens to all sources

Would it be worth specifying multiple sources?
Example: hookdeck listen 9000 source1 source2 source3

We should hide the --ws-base and --api-base from the configuration options and remove references from the docs - this is only useful for development for the internal Hookdeck team, and otherwise creates confusion.

build-mac
Node.js 16 actions are deprecated. Please update the following actions to use Node.js 20: goreleaser/goreleaser-action@v4. For more information see: https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/.

as per here: https://github.com/hookdeck/hookdeck-cli/blob/master/pkg/useragent/uname_windows.go#L6

please add :)

Hi!

I'm unable to install the Hookdeck CLI in my project using the latest Yarn version.

It fails with the following issue:

# This file contains the result of Yarn building a package (hookdeck-cli@npm:0.6.4)
# Script name: postinstall

Downloading from URL: https://github.com/hookdeck/hookdeck-cli/releases/download/v0.6.4/hookdeck_0.6.4_darwin_arm64.tar.gz
node:internal/validators:163
    throw new ERR_INVALID_ARG_TYPE(name, 'string', value);
    ^

TypeError [ERR_INVALID_ARG_TYPE]: The "path" argument must be of type string. Received null
    at new NodeError (node:internal/errors:399:5)
    at validateString (node:internal/validators:163:11)
    at Object.resolve (node:path:1098:7)
    at Function.sync (/Users/marvin/Development/orus/orus-monorepo/node_modules/go-npm-next/bin/index.js:50320:17)
    at /Users/marvin/Development/orus/orus-monorepo/node_modules/go-npm-next/bin/index.js:52476:12
    at ChildProcess.exithandler (node:child_process:427:5)
    at ChildProcess.emit (node:events:513:28)
    at maybeClose (node:internal/child_process:1091:16)
    at ChildProcess._handle.onexit (node:internal/child_process:302:5) {
  code: 'ERR_INVALID_ARG_TYPE'
}

Node.js v18.15.0

In essence, this way of installing package (https://github.com/hookdeck/go-npm/blob/master/src/index.js#L29) is broken, because packages managers (Yarn berry included) do not guarantee that the env npm_config_prefix exists.

I think there would be a cross-manager compatible way to install a binary as part of a postinstall that would work well in local and global installations:

1. The package would have a bin field looking like so:

"bin": {
  "hookdeck": "./bin/hookdeck"
},

This is how to define binaries in the package.json in a standard way.

2. Then, all that's left is, on post-install, to download the binary in the relative ./bin directory.

This has multiple benefits:

• It should be usable with all package managers
• The binary is scoped to the current installation, whether it is global or local. Hence, we can have multiple projects depending on multiple Hookdeck binaries version

Without this, my company and many more companies using monorepo setup with Yarn berry cannot use the Hookdeck CLI as part of the dependencies without running manually running npm install -g hookdeck-cli, which is a no-go for DX and dependencies stability 😕

Hi, I came across a bug with the Hookdeck API server around authentication where it won't properly authenticate requests using API key (not CLI client key) coming from the CLI. For example, this will cause an error even when the API key is valid.

$ hookdeck whoami -- api-key <VALID_API_KEY>

Here's a video where I demonstrated this issue a bit clearer: https://share.cleanshot.com/wyCX1mp3