Fix for issue #4972 "can not get domain token entry" #6469
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… validation types
Fix for empty error objects in the response which mess up the extraction of domain validation types due to the closing brace in the error object prematurely matching the end of the search pattern.
This seems to be a recent change with ZeroSSL in particular where "error":{} is being included in responses.
There could potentially be a related issue if there is a complex error object ever returned in the validation check response where an embedded sub-object could lead to an incomplete extraction of the error message, roughly around line 5040.
Adapted from fix suggested here: acmesh-official#4933 (comment)
The @epgdatacapbon was renamed to @tkmsst Signed-off-by: Sergey Ponomarev <[email protected]>
He made the DuckDNS script that was used for this script but he can't support the script. Signed-off-by: Sergey Ponomarev <[email protected]>
Signed-off-by: Sergey Ponomarev <[email protected]>
Signed-off-by: Sergey Ponomarev <[email protected]>
…I docs Signed-off-by: Sergey Ponomarev <[email protected]>
Signed-off-by: Sergey Ponomarev <[email protected]>
DNS API: Fix Structural Info
…ror-handling Run post hook when `_on_before_issue()` errors
Fix logged typo when running pre hook
Fix for empty error objects in response breaking extraction of domain validation types
New dnsapi support for OpenProvider.eu using REST API
Fix for issue 4972 (acmesh-official#4972) "can not get domain token entry" which appears to happen occasionally with ZeroSSL responses. Extends the previous fix where responses include empty response objects. Issue appears to be related to the _egrep_o regex not being able to match the `"type":"http-01"` or `"type":"dns-01"` challenge types as expected for some reason which is unclear to me. This fix adds a prior call to _egrep_o to extract the `"challenges":[{"type":"http-01",.....},{"type":"dns-01",....}]` array section of text from the response, which then appears to allow the extraction of the specific entry for the type being parsed to work.
|
Welcome |
|
@Neilpang note this fix is an addition to my previous PR relating to handling empty error objects in the ZeroSSL responses |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fix for issue #4972 (#4972) "can not get domain token entry" which appears to happen occasionally with ZeroSSL responses. Extends the previous fix where responses include empty response objects.
Issue appears to be related to the _egrep_o regex not being able to match and extract the
"type":"http-01"or"type":"dns-01"challenge type entries as expected for some reason which is unclear to me. This fix adds a prior call to _egrep_o to extract the"challenges":[{"type":"http-01",.....},{"type":"dns-01",....}]array section of text from the response, which then appears to allow the extraction of the specific entry for the type being parsed to work.