undefined | Better HN

0 pointszomglings3y ago0 comments

Actually, I hadn't considered that signup use case at all. Good point. It could be a useful way of offloading heavy data processing to Jiter.

It would be useful to see on your website what the webhook request from Jiter.dev would look like. How does the receiver know that the webhook came from Jiter with no tampering by a middleman? Is there a signature that the user could verify? (Slack does this well on their webhooks.)

Congratulations on the launch, and I wish you the best!

0 comments

3 comments · 1 top-level

skaiser3y ago· 2 in thread

Yea we think it's a solid use case (mostly because we had that problem ourselves with a previous product haha)

And another great question! We use signing secrets to create a signature so you can validate that the request from us is authentic.

And thanks! This is just the beginning for us, so hopefully you give us a chance and sign up so we can notify you as we release new features!

sneak3y ago

If you are using signing secrets, consider having the client keep a secret and simply encrypt and sign the payload before handing it off to you.

When it comes back in, they can decrypt and authenticate it. You could hide all this in your api client.

Then you don’t end up with a big centralized database full of the PII of millions of your customers’ customers.

skaiser3y ago

So are you suggesting that we update docs to encourage users to do that? We use signing secrets to sign the payload so users know the request from us is authentic, but other than that I can't think of how we'd control what users send us aside from just rejecting anything that "looks" like an object ;)

I do like the idea of including a little chunk in our SDK (Coming soon!) to allow them to easily encrypt/decrypt their payload, but that'd be entirely on them to follow that practice.

1 more reply

j / k navigate · click thread line to collapse