Open zoryatix opened 3 weeks ago
Congratulations, @zoryatix! At first glance, this looks great. The only minor thing you might want to do in future PRs is put your changes in their own git branch. It makes it a tiny bit easier for someone to pull down your branch to their local repo for testing.
Give me a bit to review things more thoroughly and we'll get this merged.
Thanks - git is a whole new world for me. Thanks for taking the time to explain the flow, I'll keep that in mind.
I just noticed that the user guide talks about getting API credentials by contacting support through a reseller. What about customers who purchase directly through EuroDNS? Ironically, despite there clearly being API documentation, I can't actually find a reference on their site that the API exists or how to get credentials for it.
That is very good question. I tried reaching out to EuroDNS through their support site, asking a question during development. They just sent that question back to ebrand. My contact at ebrand said that all communication should go through them. So, it's a bit of a weird setup.
I had to get my api key through my contact person at ebrand. Assuming that they contacted eurodns on my behalf.
Plot thickens. I reached out to EuroDNS support to ask how to generate API credentials and this was their response.
Unfortunately, our API is a dedicated tool for our resellers, to enable them to automate their domain purchases. Unless we're mistaken, it would appear that you don't have reseller status . A new API will be available to all in the near future (docapi) , but our team is still working on it.
It sounds like EBrand is essentially distributing credentials on behalf of their reseller status that aren't necessarily intended for end users (unless you actually are a reseller).
I'm not opposed to adding the plugin as-is. But I'll probably update the guide to say it's only going to be useful if you're a EuroDNS reseller or a customer of a reseller that is willing to generate API credentials on your behalf. I'm also trying to decide whether the name should change to something like EuroDNSReseller
just in case the "new API" is significantly different and justifies a distinct plugin.
Nice find - I had no idea the structure was setup like that. I don't mind the name change, but many of the functions i built were using EuroDNS in their name, so that would also need to be changed, to avoid a conflict in case someone builds a plugin for the "new api". The name EuroDNSResller sounds good to me as long as documentation mentions ebrand, so that people searching for that name can find the plugin.
I just noticed that you've got a bug in the code that tries to parse the zone/domain from $RecordName
. It doesn't work for third level domains such as example.co.uk
.
VERBOSE: Publishing challenge for Domain example.co.uk with Token a using Plugin EuroDNS and DnsAlias ''.
VERBOSE: Looking for Zonename in _acme-challenge.example.co.uk...
VERBOSE: Found: co.uk
The typical way plugins handle this is by querying the provider for increasingly generic portions of the $RecordName until it either finds a match or gives up and throws an error. So if your $RecordName
starts out as _acme-challenge.www.example.co.uk
, you basically ask the provider:
_acme-challenge.www.example.co.uk
zone exist? (No, loop)www.example.co.uk
zone exist? (No, loop)example.co.uk
zone exist? (Yes, return)Have a look at the DOcean plugin's Find-DOZone
function for a decent example of this.
Ohh nice catch - I'll take a look at DOcean and create a fix for mine. I might as well rename the plugin. I'm happy with EuroDNSReseller, so I'll go ahead and change it to that if you don't mind.
First time doing a pull request. No idea if I'm doing this right. Below has been tested according to the plugin development guide and have successfully been able to get a certificate through the:
New-PACertificate '*.MyExampleDomain.com','MyExampleDomain.com' -AcceptTOS -Contact 'contact@MyExampleDomain.com' -Plugin EuroDNS -PluginArgs $pArgs -Verbose