RFC: Foreman webhooks

[Marek_Hulan]

Nice overview, some comments regarding Netbox webhooks

@lzap

Enabled - If unchecked, the webhook will be inactive.

we should add that too

@lzap

Additional headers - Any additional headers to include with the request (optional). Add one header per line in the format Name: Value . Jinja2 templating is supported for this field (see below).

this is also nice thing, with this people can use the engine until we more request capabilities as a first class citizen

@lzap

Body template - The content of the request being sent (optional). Jinja2 templating is supported for this field (see below). If blank, NetBox will populate the request body with a raw dump of the webhook context. (If the HTTP cotent type is set to application/json , this will be formatted as a JSON object.)

I like this behavior, it’s a combination of what we discussed in the PR.

@lzap

• SSL verification - Uncheck this option to disable validation of the receiver’s SSL certificate. (Disable with caution!)
• CA file path - The file path to a particular certificate authority (CA) file to use when validating the receiver’s SSL certificate (optional).

we should also add these

Regarding the authn methods - even tower supports that even though oauth2 is recommended. I looked at icinga and it allows HTTP basic and x509 (yet another method). I’d start with HTTP basic as it’s almost everywhere. Once we have basic auth, we can add oauth2 tokens support.

[TimoGoebel]

@Marek_Hulan

we should also add these

Yes, but let’s make sure we store the CA data in the database and not just reference to a file on the server. This makes it easier from an operations perspective and we can actually validate if the CA data is valid.

Another great feature might be to log the hook request so you can investigate the return codes and replay a request. That pretty valuable for debugging the webhooks.

Generally speaking, let’s try this approach. I’m all for it now. After the discussion you have me almost convinced this is a good idea

[TimoGoebel]

@lzap

So I suggest to go with our proposal, unless there is something I don’ t see. What you think?

I’d say: Let’s start with basic auth for now and provide a way to store the credentials for that in a safe manner. I believe we should focus on making this work well first before we make it more complicated.

[lzap]

@Marek_Hulan

we should also add these

Created a RM ticket: Refactor #30707: Refactor webhook model - Webhooks - Foreman

I think all of them are applicable except Secret and Object Type.

[lzap]

@TimoGoebel

Yes, but let’s make sure we store the CA data in the database and not just reference to a file on the server. This makes it easier from an operations perspective and we can actually validate if the CA data is valid.

Absolutely, similarly we do for CRs.

@TimoGoebel

Another great feature might be to log the hook request so you can investigate the return codes and replay a request. That pretty valuable for debugging the webhooks.

https://projects.theforeman.org/issues/30707

[ekohl]

I think secret to provide a HMAC signed delivery is actually a good feature. Github also uses this in their webhooks, without implementing any other auth.