Open leamas opened 2 years ago
Could the new auth plugins fix the limitation we had with netrc? Namely, the limitation of only being able to key on a hostname? Both decisions discussed in #52 and #56, to mangle the hostname and copy-paste modified versions of auth functions, were because of following those limitations. By introducing auth plugins, you have the opportunity to pass sufficient parameters to get_auth. The netrc plugin could go back to ignoring everything but the hostname.
Patch looks like it would work at a glance, but the design isn't evolving in a very directed way.
Anyhing is possible. However, one basic ramification is that get_netrc_auth will stay as it is -- I have declared a promise to stay API compatible up to 1.0.0.We could add a new method, though.
OTOH, backends are limited to a single key -> password mapping, so we need to apply tricks like those here to use a composite key. And netrc requires that the key at least resembles a dns hostname, I guess.
It's similar when it comes to the username/pw credentials, the keyring only maps a key -> password, so the username is stored together with the password.
In short, creating complicates schemas makes using different backends harder, I guess.
Going back to your problem here: Can you use plugin options to add hosts? Yes, you would need to handle the passwords manually, but this is now supported bu ddupdate -p
. A standard configuration + some extra hosts proviced as plugin options -- shouldn't that make the trick?
but the design isn't evolving in a very directed way.
The direction is conservative, for sure. Trying to keep compatibility, that is.
The googledomains plugin in a bad state after merging #23 since it always uses .netrc, disregarding configuration of credentials source. I have patched the plugin in 66ba183 to cope with this.
@g2p : Have you any chance to review my patch?