Raise an error when the HTTP challenge is nil #71
Conversation
This file contains 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
Until there is support for proper DNS validation, which I might look at building in again now, we need an error to fire when no HTTP challenge is available for whatever reason.
|
@mashedkeyboard I'm so sorry, I somehow never saw this come in. I've put it on my list to check & merge in as soon as I can. Thx for your patience! |
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.
Spotted this issue way back when the original ACME v2 implementation was being done, but it's pretty minor, so it doesn't look like it got picked up.
For now, this just raises an error; in future, this should use a DNS challenge if that's available, though. I did a lot of work on that in #60, which I might try and work some more on now - CloudFlare's new API tokens are here, so we can get it set up with that at least as supported DNS, and I'll build in providers as being modular so others can contribute others as and when needed.
Either way, for now, this PR addresses #69 - although perhaps not in a hugely satisfactory way, beyond just "not throwing some random file access stack trace".