Pass CHALLENGETYPE to hook.sh for deploy_challenge, clean_challenge, and invalid_challenge #173

New Issue

adam · 2025-12-29T00:26:27+01:00

adam commented

2025-12-29 00:26:27 +01:00

Originally created by @whereisaaron on GitHub (Dec 23, 2016).

dehydrated allows for per-certificate configuration of various parameters including the CHALLENGETYPE (e.g. http-01 or dns-01). I'd like to propose this parameter is passed to the challenge related functions in the HOOK script (if any).

This would e.g. allow the hook script to only create dns-01 challenge records for those challenges, and do nothing or something different for http-01 challenges.

The CHALLENGETYPE parameter would be added at an additional/last parameter to:

deploy_challenge
clean_challenge
invalid_challenge

and so and would be backwards compatible with existing hook scripts.

The CHALLENGETYPE could be an extra parameter for the HOOK_CHAIN case of X*Y parameters, but this would be a breaking change for people using HOOK_CHAIN. The extra parameter could also be entirely omitted in the HOOK_CHAIN case to maintain backward compatibility.

It is possible to achieve the same result by specifying per-certificate hook scripts, and maintaining separate hook scripts for each challenge type. However as the number of challenge types will grow over time, it seems more cumbersome than parameterizing a single script.

What to people think?

Originally created by @whereisaaron on GitHub (Dec 23, 2016). `dehydrated` allows for per-certificate configuration of various parameters including the `CHALLENGETYPE` (e.g. `http-01` or `dns-01`). I'd like to propose this parameter is passed to the challenge related functions in the `HOOK` script (if any). This would e.g. allow the hook script to only create `dns-01` challenge records for those challenges, and do nothing or something different for `http-01` challenges. The CHALLENGETYPE parameter would be added at an additional/last parameter to: * `deploy_challenge` * `clean_challenge` * `invalid_challenge` and so and would be backwards compatible with existing hook scripts. The `CHALLENGETYPE` could be an extra parameter for the HOOK_CHAIN case of X*Y parameters, but this would be a breaking change for people using `HOOK_CHAIN`. The extra parameter could also be entirely omitted in the `HOOK_CHAIN` case to maintain backward compatibility. It is possible to achieve the same result by specifying per-certificate hook scripts, and maintaining separate hook scripts for each challenge type. However as the number of challenge types will grow over time, it seems more cumbersome than parameterizing a single script. What to people think?

adam closed this issue

2025-12-29 00:26:27 +01:00

adam commented

2025-12-29 00:26:29 +01:00

@lukas2511 commented on GitHub (Jan 29, 2017):

I exported a few variables in 57197306d7, you should now be able to just pull them from the environment variables in your hooks, no changes to the existing hooks required.

@lukas2511 commented on GitHub (Jan 29, 2017): I exported a few variables in 57197306d7d19d87b3b6b5deadd640d72cbe5f31, you should now be able to just pull them from the environment variables in your hooks, no changes to the existing hooks required.

adam commented

2025-12-29 00:26:30 +01:00

@whereisaaron commented on GitHub (Jan 30, 2017):

That will work, thanks for exporting that!

As a comment. I think the challenge type is a pretty intrinsic part if a hook call, since the hook script is there to facilitate the challenge types. So I would have thought it would be the first challenge hook call argument, right before or after the domain name. But the export is equally as functional, so I'll take it and shut up 😉

@whereisaaron commented on GitHub (Jan 30, 2017): That will work, thanks for exporting that! As a comment. I think the challenge type is a pretty intrinsic part if a hook call, since the hook script is there to facilitate the challenge types. So I would have thought it would be the first challenge hook call argument, right before or after the domain name. But the export is equally as functional, so I'll take it and shut up 😉

adam referenced this issue

2025-12-29 01:28:46 +01:00

[PR #173] [CLOSED] Using alias instead of root in cases where root does not work #744

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/dehydrated#173