service definition about python-dyndnsc HOT 6 CLOSED

First approach, what do you think?

Service Definitions (could be builtin services.conf + userdefined in /etc):

[nsupdate.info]
protocol = dyndns2
query_ip = http://nsupdate.info/myip
query_ipv4 = http://ipv4.nsupdate.info/myip
query_ipv6 = http://ipv6.nsupdate.info/myip
query_tls_support = True
query_response_parser = plain
update = http://nsupdate.info/nic/update
update_tls_support = True
update_interval_forced = 30 # days

Updater Configurations (userdefined in /etc):

[my_ipv4_updater]
enabled = True
service = nsupdate.info # services.ini section name
family = ipv4 # this updater only deals with IPv4
query_method = web
query_tls = True
update_tls = True
auth_name = myhost.nsupdate.info # for other services, could be user's name
auth_secret = 123456 # for other services, could be user's password
hostnames = myhost.nsupdate.info # optionally multiple, comma-separated

[my_ipv6_updater]
enabled = True
service = nsupdate.info # services.ini section name
family = ipv6
query_method = socket
update_tls = True
auth_name = myhost.nsupdate.info # for other services, could be user's name
auth_secret = 123456 # for other services, could be user's password
hostnames = myhost.nsupdate.info # optionally multiple, comma-separated

from python-dyndnsc.

As it looks, I think a service definition is going too far. All we need and can implement as such a config file is a set of defaults that are known to work well.

For example:

[no-ip.com]
update = dyndns2
update-url = https://dynupdate.no-ip.com/nic/update
detect = webcheck4
detect-family = inet
detect-url = http://ip1.dynupdate.no-ip.com/
detect-parser = plain

[nsupdate.info:ipv4]
update = dyndns2
update-url = https://nsupdate.info/nic/update
detect = webcheck4
detect-family = inet
detect-url = https://ipv4.nsupdate.info/myip
detect-parser = plain

[nsupdate.info:ipv6]
update = dyndns2
update-url = https://nsupdate.info/nic/update
detect = webcheck6
detect-family = inet6
detect-url = https://ipv6.nsupdate.info/myip
detect-parser = plain

from python-dyndnsc.

with your config, you could not:

have a secure default for services with good tls support AND have an easy user config toggle to switch it off, if wanted. also to define insecure-only services and being able find unsupported tls requests in the user's config.

avoid specifying / editing urls (e.g. for http <-> https) by user.

for some cases, this would lead to multiple such default definitions (2 for v4/v6, 2 for tls/no-tls, ...) for 1 service.

the "enabled" was inspired by openwrt, btw. - iirc they generally use it for a checkbox in a web interface to simply switch stuff off (on) without having to remove (readd) it.

btw, I'ld appreciate if the update basic auth credentials would be named in a rather generic and non-misleading way, not "username" and "password". I tried that with "auth_name" and "auth_secret" (for nsupdate.info, name refers to the host fqdn [not username], secret is a autogenerated random token [not user's web login password]).

from python-dyndnsc.

I see that you want user friendliness. When it comes to implementing security features for end-users, I'd rather avoid implementing boolean switches for switching protocols of URLs somewhere in the code. Explicitly saying 'https' is pretty clear. You are right that this leads to more presets than one might feel are needed, but then again you'd need to have an abstraction layer for a service that has "capabilities". Such capabilities could even potentially be discovered/probed by the client...

from python-dyndnsc.

TLDR custom argument names require more code
W.r.t. naming conventions like userid vs auth_name: the implementation that is in place allows us to completely remove the custom code/classes for separate services. This however means that all compatible services will be serviced by the same initargs. The only way in the long run to provide separately named arguments is to maintain separate classes that will either subclass or wrap the actual implementations.

W.r.t. the original ticket goal: updaters and detector are now tied together using "profiles", simple to use presets for configuration. Staying within ipv4 or ipv6 bounds automatically was also implemented. I see no point in coupling these things in the code (i.e. not configurable).

Closing.

from python-dyndnsc.

I didn't speak about "custom argument names", I just wished that the arg names are made in a way that is generic (and not misleading). If you name the basic auth credentials like "username" and "password", users will enter their personal name there and likely also their personal login password.

For some services, this is what is wanted, for some not. If one just says "auth_name", it doesn't say "user" (nor "host"), so the user can insert whatever name is needed there.

from python-dyndnsc.