[PATCH] ddns.cgi: Drop static provider list for token based auth.

[PATCH] ddns.cgi: Drop static provider list for token based auth.

[Stefan Schantl]

[-- Attachment #1: Type: text/plain, Size: 1094 bytes --]

This is really hard to maintain when adding new or altering existing
providers.

Reference #12415.

Signed-off-by: Stefan Schantl <stefan.schantl(a)ipfire.org>
---
 html/cgi-bin/ddns.cgi | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/html/cgi-bin/ddns.cgi b/html/cgi-bin/ddns.cgi
index 715c37290..024eaf7f6 100644
--- a/html/cgi-bin/ddns.cgi
+++ b/html/cgi-bin/ddns.cgi
@@ -665,13 +665,13 @@ sub GenerateDDNSConfigFile {
 
 		my $use_token = 0;
 
-		# Handle token based auth for various providers.
-		if ($provider ~~ ["dns.lightningwirelabs.com", "entrydns.net", "regfish.com",
-				  "spdns.de", "zzzz.io"] && $username eq "token") {
+		# Check if token based auth is configured.
+		if ($username eq "token") {
 			$use_token = 1;
+		}
 
 		# Handle token auth for freedns.afraid.org and regfish.com.
-		} elsif ($provider ~~ ["freedns.afraid.org", "regfish.com"] && $password eq "") {
+		if ($provider ~~ ["freedns.afraid.org", "regfish.com"] && $password eq "") {
 			$use_token = 1;
 			$password = $username;
 
-- 
2.20.1

Re: [PATCH] ddns.cgi: Drop static provider list for token based auth.

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 1531 bytes --]

Hello,

I do not understand exactly what this patch is trying to achieve.

Unfortunately we have no choice than doing it this way with the current UI.

I do not think it is worth altering the UI for this, and I do not know how we could do it without having a list again?

-Michael

> On 2 Dec 2020, at 11:30, Stefan Schantl <stefan.schantl(a)ipfire.org> wrote:
> 
> This is really hard to maintain when adding new or altering existing
> providers.
> 
> Reference #12415.
> 
> Signed-off-by: Stefan Schantl <stefan.schantl(a)ipfire.org>
> ---
> html/cgi-bin/ddns.cgi | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/html/cgi-bin/ddns.cgi b/html/cgi-bin/ddns.cgi
> index 715c37290..024eaf7f6 100644
> --- a/html/cgi-bin/ddns.cgi
> +++ b/html/cgi-bin/ddns.cgi
> @@ -665,13 +665,13 @@ sub GenerateDDNSConfigFile {
> 
> 		my $use_token = 0;
> 
> -		# Handle token based auth for various providers.
> -		if ($provider ~~ ["dns.lightningwirelabs.com", "entrydns.net", "regfish.com",
> -				  "spdns.de", "zzzz.io"] && $username eq "token") {
> +		# Check if token based auth is configured.
> +		if ($username eq "token") {
> 			$use_token = 1;
> +		}
> 
> 		# Handle token auth for freedns.afraid.org and regfish.com.
> -		} elsif ($provider ~~ ["freedns.afraid.org", "regfish.com"] && $password eq "") {
> +		if ($provider ~~ ["freedns.afraid.org", "regfish.com"] && $password eq "") {
> 			$use_token = 1;
> 			$password = $username;
> 
> -- 
> 2.20.1
> 

Re: [PATCH] ddns.cgi: Drop static provider list for token based auth.

[Stefan Schantl]

[-- Attachment #1: Type: text/plain, Size: 3335 bytes --]

Hello Michael,

the intension of this patch was, that a supported provider of DDNS has
changed it's API to support now token based authentication. The code
already has been changed so here we are safe by now.

Also in case a new dynamic DNS provider will be added to DDNS, we do
not have to do anything, because the GUI automatically will be filled
with the new provider.

But there is one big exception in this:

If a new or existing provider has supports authentication tokens, this
provider has to be added to this list, which is not very intuitive.

We also have to ship the GUI each time for new, if this happened.

(This was the former reason, why we created the "ddns list-providers"
command to prevent from this.)

My change simplifies, the check if token based authentication should be
used or not. It removes the check against the static list of providers
which supports token based authentications. (This is the list, which
needs to be keep up to date by hand.)

For the user nothing changes, because if he speciefies "token" as
username, still the token base auth will be used for the choosen
provider.

The only way an user may be affected is, if he configures a token based
auth for a provider which does not supports it. This now would be
possible and will result in an authentication error against the
provider - But Hey, if he fills in incorrect data the same will be
happen.

The only bigger problem would be if the valid username of a user is
"token". In this case he will be affected in the same way and this
could not be fixed in an easy way.

IMHO, the benefits are bigger for us, because the maintain work will
become much easier and one stupid error source will get eliminated.

Best regards,

-Stefan 
> Hello,
> 
> I do not understand exactly what this patch is trying to achieve.
> 
> Unfortunately we have no choice than doing it this way with the
> current UI.
> 
> I do not think it is worth altering the UI for this, and I do not
> know how we could do it without having a list again?
> 
> -Michael
> 
> > On 2 Dec 2020, at 11:30, Stefan Schantl <stefan.schantl(a)ipfire.org>
> > wrote:
> > 
> > This is really hard to maintain when adding new or altering
> > existing
> > providers.
> > 
> > Reference #12415.
> > 
> > Signed-off-by: Stefan Schantl <stefan.schantl(a)ipfire.org>
> > ---
> > html/cgi-bin/ddns.cgi | 8 ++++----
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> > 
> > diff --git a/html/cgi-bin/ddns.cgi b/html/cgi-bin/ddns.cgi
> > index 715c37290..024eaf7f6 100644
> > --- a/html/cgi-bin/ddns.cgi
> > +++ b/html/cgi-bin/ddns.cgi
> > @@ -665,13 +665,13 @@ sub GenerateDDNSConfigFile {
> > 
> > 		my $use_token = 0;
> > 
> > -		# Handle token based auth for various providers.
> > -		if ($provider ~~ ["dns.lightningwirelabs.com",
> > "entrydns.net", "regfish.com",
> > -				  "spdns.de", "zzzz.io"] && $username
> > eq "token") {
> > +		# Check if token based auth is configured.
> > +		if ($username eq "token") {
> > 			$use_token = 1;
> > +		}
> > 
> > 		# Handle token auth for freedns.afraid.org and
> > regfish.com.
> > -		} elsif ($provider ~~ ["freedns.afraid.org",
> > "regfish.com"] && $password eq "") {
> > +		if ($provider ~~ ["freedns.afraid.org", "regfish.com"]
> > && $password eq "") {
> > 			$use_token = 1;
> > 			$password = $username;
> > 
> > -- 
> > 2.20.1
> > 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] ddns.cgi: Drop static provider list for token based auth.

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 3688 bytes --]

Hi,

You are moving the problem from the developer to the user.

I think that might be more messy.

I am also not sure how this will affect existing setups?

-Michael

> On 2 Dec 2020, at 15:35, Stefan Schantl <stefan.schantl(a)ipfire.org> wrote:
> 
> Hello Michael,
> 
> the intension of this patch was, that a supported provider of DDNS has
> changed it's API to support now token based authentication. The code
> already has been changed so here we are safe by now.
> 
> Also in case a new dynamic DNS provider will be added to DDNS, we do
> not have to do anything, because the GUI automatically will be filled
> with the new provider.
> 
> But there is one big exception in this:
> 
> If a new or existing provider has supports authentication tokens, this
> provider has to be added to this list, which is not very intuitive.
> 
> We also have to ship the GUI each time for new, if this happened.
> 
> (This was the former reason, why we created the "ddns list-providers"
> command to prevent from this.)
> 
> My change simplifies, the check if token based authentication should be
> used or not. It removes the check against the static list of providers
> which supports token based authentications. (This is the list, which
> needs to be keep up to date by hand.)
> 
> For the user nothing changes, because if he speciefies "token" as
> username, still the token base auth will be used for the choosen
> provider.
> 
> The only way an user may be affected is, if he configures a token based
> auth for a provider which does not supports it. This now would be
> possible and will result in an authentication error against the
> provider - But Hey, if he fills in incorrect data the same will be
> happen.
> 
> The only bigger problem would be if the valid username of a user is
> "token". In this case he will be affected in the same way and this
> could not be fixed in an easy way.
> 
> IMHO, the benefits are bigger for us, because the maintain work will
> become much easier and one stupid error source will get eliminated.
> 
> Best regards,
> 
> -Stefan 
>> Hello,
>> 
>> I do not understand exactly what this patch is trying to achieve.
>> 
>> Unfortunately we have no choice than doing it this way with the
>> current UI.
>> 
>> I do not think it is worth altering the UI for this, and I do not
>> know how we could do it without having a list again?
>> 
>> -Michael
>> 
>>> On 2 Dec 2020, at 11:30, Stefan Schantl <stefan.schantl(a)ipfire.org>
>>> wrote:
>>> 
>>> This is really hard to maintain when adding new or altering
>>> existing
>>> providers.
>>> 
>>> Reference #12415.
>>> 
>>> Signed-off-by: Stefan Schantl <stefan.schantl(a)ipfire.org>
>>> ---
>>> html/cgi-bin/ddns.cgi | 8 ++++----
>>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>> 
>>> diff --git a/html/cgi-bin/ddns.cgi b/html/cgi-bin/ddns.cgi
>>> index 715c37290..024eaf7f6 100644
>>> --- a/html/cgi-bin/ddns.cgi
>>> +++ b/html/cgi-bin/ddns.cgi
>>> @@ -665,13 +665,13 @@ sub GenerateDDNSConfigFile {
>>> 
>>> 		my $use_token = 0;
>>> 
>>> -		# Handle token based auth for various providers.
>>> -		if ($provider ~~ ["dns.lightningwirelabs.com",
>>> "entrydns.net", "regfish.com",
>>> -				  "spdns.de", "zzzz.io"] && $username
>>> eq "token") {
>>> +		# Check if token based auth is configured.
>>> +		if ($username eq "token") {
>>> 			$use_token = 1;
>>> +		}
>>> 
>>> 		# Handle token auth for freedns.afraid.org and
>>> regfish.com.
>>> -		} elsif ($provider ~~ ["freedns.afraid.org",
>>> "regfish.com"] && $password eq "") {
>>> +		if ($provider ~~ ["freedns.afraid.org", "regfish.com"]
>>> && $password eq "") {
>>> 			$use_token = 1;
>>> 			$password = $username;
>>> 
>>> -- 
>>> 2.20.1
>>> 

Re: [PATCH] ddns.cgi: Drop static provider list for token based auth.

[Stefan Schantl]

[-- Attachment #1: Type: text/plain, Size: 4639 bytes --]

Mhm,

you are right this will only move the problem from the developers (us)
to the users.

This is a really hard problem because there is no easy solution for
this issue.

We simple can take care about the users input and verify if the
providers supports what has been configured or we even do not.

If we decide to safe the users from themself, we need something to
verify against and that would be something like such a crappy static
list.

Do I miss something or think to narrow?

@List followers, what are your opinions?

Best regards,

-Stefan
> 
> You are moving the problem from the developer to the user.
> 
> I think that might be more messy.
> 
> I am also not sure how this will affect existing setups?
> 
> -Michael
> 
> > On 2 Dec 2020, at 15:35, Stefan Schantl <stefan.schantl(a)ipfire.org>
> > wrote:
> > 
> > Hello Michael,
> > 
> > the intension of this patch was, that a supported provider of DDNS
> > has
> > changed it's API to support now token based authentication. The
> > code
> > already has been changed so here we are safe by now.
> > 
> > Also in case a new dynamic DNS provider will be added to DDNS, we
> > do
> > not have to do anything, because the GUI automatically will be
> > filled
> > with the new provider.
> > 
> > But there is one big exception in this:
> > 
> > If a new or existing provider has supports authentication tokens,
> > this
> > provider has to be added to this list, which is not very intuitive.
> > 
> > We also have to ship the GUI each time for new, if this happened.
> > 
> > (This was the former reason, why we created the "ddns list-
> > providers"
> > command to prevent from this.)
> > 
> > My change simplifies, the check if token based authentication
> > should be
> > used or not. It removes the check against the static list of
> > providers
> > which supports token based authentications. (This is the list,
> > which
> > needs to be keep up to date by hand.)
> > 
> > For the user nothing changes, because if he speciefies "token" as
> > username, still the token base auth will be used for the choosen
> > provider.
> > 
> > The only way an user may be affected is, if he configures a token
> > based
> > auth for a provider which does not supports it. This now would be
> > possible and will result in an authentication error against the
> > provider - But Hey, if he fills in incorrect data the same will be
> > happen.
> > 
> > The only bigger problem would be if the valid username of a user is
> > "token". In this case he will be affected in the same way and this
> > could not be fixed in an easy way.
> > 
> > IMHO, the benefits are bigger for us, because the maintain work
> > will
> > become much easier and one stupid error source will get eliminated.
> > 
> > Best regards,
> > 
> > -Stefan 
> > > Hello,
> > > 
> > > I do not understand exactly what this patch is trying to achieve.
> > > 
> > > Unfortunately we have no choice than doing it this way with the
> > > current UI.
> > > 
> > > I do not think it is worth altering the UI for this, and I do not
> > > know how we could do it without having a list again?
> > > 
> > > -Michael
> > > 
> > > > On 2 Dec 2020, at 11:30, Stefan Schantl <
> > > > stefan.schantl(a)ipfire.org>
> > > > wrote:
> > > > 
> > > > This is really hard to maintain when adding new or altering
> > > > existing
> > > > providers.
> > > > 
> > > > Reference #12415.
> > > > 
> > > > Signed-off-by: Stefan Schantl <stefan.schantl(a)ipfire.org>
> > > > ---
> > > > html/cgi-bin/ddns.cgi | 8 ++++----
> > > > 1 file changed, 4 insertions(+), 4 deletions(-)
> > > > 
> > > > diff --git a/html/cgi-bin/ddns.cgi b/html/cgi-bin/ddns.cgi
> > > > index 715c37290..024eaf7f6 100644
> > > > --- a/html/cgi-bin/ddns.cgi
> > > > +++ b/html/cgi-bin/ddns.cgi
> > > > @@ -665,13 +665,13 @@ sub GenerateDDNSConfigFile {
> > > > 
> > > > 		my $use_token = 0;
> > > > 
> > > > -		# Handle token based auth for various
> > > > providers.
> > > > -		if ($provider ~~ ["dns.lightningwirelabs.com",
> > > > "entrydns.net", "regfish.com",
> > > > -				  "spdns.de", "zzzz.io"] &&
> > > > $username
> > > > eq "token") {
> > > > +		# Check if token based auth is configured.
> > > > +		if ($username eq "token") {
> > > > 			$use_token = 1;
> > > > +		}
> > > > 
> > > > 		# Handle token auth for freedns.afraid.org and
> > > > regfish.com.
> > > > -		} elsif ($provider ~~ ["freedns.afraid.org",
> > > > "regfish.com"] && $password eq "") {
> > > > +		if ($provider ~~ ["freedns.afraid.org",
> > > > "regfish.com"]
> > > > && $password eq "") {
> > > > 			$use_token = 1;
> > > > 			$password = $username;
> > > > 
> > > > -- 
> > > > 2.20.1
> > > > 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] ddns.cgi: Drop static provider list for token based auth.

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 5321 bytes --]

Hi,

Alternatives I could come up with are:

* Create a command to have ddns list all those providers. That way that list is in ddns where it probably belongs best.

* Update the UI and add a third field for the token. That is however very bad UI because either the token field or the username/password field are a waste of space.

Actually, we need to work towards having token only. Anything else is just dangerous because the whole account can be managed if this data leaks.

-Michael

> On 2 Dec 2020, at 16:02, Stefan Schantl <stefan.schantl(a)ipfire.org> wrote:
> 
> Mhm,
> 
> you are right this will only move the problem from the developers (us)
> to the users.
> 
> This is a really hard problem because there is no easy solution for
> this issue.
> 
> We simple can take care about the users input and verify if the
> providers supports what has been configured or we even do not.
> 
> If we decide to safe the users from themself, we need something to
> verify against and that would be something like such a crappy static
> list.
> 
> Do I miss something or think to narrow?
> 
> @List followers, what are your opinions?
> 
> Best regards,
> 
> -Stefan
>> 
>> You are moving the problem from the developer to the user.
>> 
>> I think that might be more messy.
>> 
>> I am also not sure how this will affect existing setups?
>> 
>> -Michael
>> 
>>> On 2 Dec 2020, at 15:35, Stefan Schantl <stefan.schantl(a)ipfire.org>
>>> wrote:
>>> 
>>> Hello Michael,
>>> 
>>> the intension of this patch was, that a supported provider of DDNS
>>> has
>>> changed it's API to support now token based authentication. The
>>> code
>>> already has been changed so here we are safe by now.
>>> 
>>> Also in case a new dynamic DNS provider will be added to DDNS, we
>>> do
>>> not have to do anything, because the GUI automatically will be
>>> filled
>>> with the new provider.
>>> 
>>> But there is one big exception in this:
>>> 
>>> If a new or existing provider has supports authentication tokens,
>>> this
>>> provider has to be added to this list, which is not very intuitive.
>>> 
>>> We also have to ship the GUI each time for new, if this happened.
>>> 
>>> (This was the former reason, why we created the "ddns list-
>>> providers"
>>> command to prevent from this.)
>>> 
>>> My change simplifies, the check if token based authentication
>>> should be
>>> used or not. It removes the check against the static list of
>>> providers
>>> which supports token based authentications. (This is the list,
>>> which
>>> needs to be keep up to date by hand.)
>>> 
>>> For the user nothing changes, because if he speciefies "token" as
>>> username, still the token base auth will be used for the choosen
>>> provider.
>>> 
>>> The only way an user may be affected is, if he configures a token
>>> based
>>> auth for a provider which does not supports it. This now would be
>>> possible and will result in an authentication error against the
>>> provider - But Hey, if he fills in incorrect data the same will be
>>> happen.
>>> 
>>> The only bigger problem would be if the valid username of a user is
>>> "token". In this case he will be affected in the same way and this
>>> could not be fixed in an easy way.
>>> 
>>> IMHO, the benefits are bigger for us, because the maintain work
>>> will
>>> become much easier and one stupid error source will get eliminated.
>>> 
>>> Best regards,
>>> 
>>> -Stefan 
>>>> Hello,
>>>> 
>>>> I do not understand exactly what this patch is trying to achieve.
>>>> 
>>>> Unfortunately we have no choice than doing it this way with the
>>>> current UI.
>>>> 
>>>> I do not think it is worth altering the UI for this, and I do not
>>>> know how we could do it without having a list again?
>>>> 
>>>> -Michael
>>>> 
>>>>> On 2 Dec 2020, at 11:30, Stefan Schantl <
>>>>> stefan.schantl(a)ipfire.org>
>>>>> wrote:
>>>>> 
>>>>> This is really hard to maintain when adding new or altering
>>>>> existing
>>>>> providers.
>>>>> 
>>>>> Reference #12415.
>>>>> 
>>>>> Signed-off-by: Stefan Schantl <stefan.schantl(a)ipfire.org>
>>>>> ---
>>>>> html/cgi-bin/ddns.cgi | 8 ++++----
>>>>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>>>> 
>>>>> diff --git a/html/cgi-bin/ddns.cgi b/html/cgi-bin/ddns.cgi
>>>>> index 715c37290..024eaf7f6 100644
>>>>> --- a/html/cgi-bin/ddns.cgi
>>>>> +++ b/html/cgi-bin/ddns.cgi
>>>>> @@ -665,13 +665,13 @@ sub GenerateDDNSConfigFile {
>>>>> 
>>>>> 		my $use_token = 0;
>>>>> 
>>>>> -		# Handle token based auth for various
>>>>> providers.
>>>>> -		if ($provider ~~ ["dns.lightningwirelabs.com",
>>>>> "entrydns.net", "regfish.com",
>>>>> -				  "spdns.de", "zzzz.io"] &&
>>>>> $username
>>>>> eq "token") {
>>>>> +		# Check if token based auth is configured.
>>>>> +		if ($username eq "token") {
>>>>> 			$use_token = 1;
>>>>> +		}
>>>>> 
>>>>> 		# Handle token auth for freedns.afraid.org and
>>>>> regfish.com.
>>>>> -		} elsif ($provider ~~ ["freedns.afraid.org",
>>>>> "regfish.com"] && $password eq "") {
>>>>> +		if ($provider ~~ ["freedns.afraid.org",
>>>>> "regfish.com"]
>>>>> && $password eq "") {
>>>>> 			$use_token = 1;
>>>>> 			$password = $username;
>>>>> 
>>>>> -- 
>>>>> 2.20.1
>>>>> 

Re: [PATCH] ddns.cgi: Drop static provider list for token based auth.

[Stefan Schantl]

[-- Attachment #1: Type: text/plain, Size: 6664 bytes --]

Hi,
> Hi,
> 
> Alternatives I could come up with are:
> 
> * Create a command to have ddns list all those providers. That way
> that list is in ddns where it probably belongs best.

This probably would be the best solution.

So I'm thinking about to introduce something like "supports_token_auth
= True" similar to "can_remove_records = True" in the source file which
handles the providers.

After that, adding a new command option, which outputs the providers
with this flag similar to the "ddns list-providers" option.

In this case we will get a dynamically generated list of what we want
and need. 

> 
> * Update the UI and add a third field for the token. That is however
> very bad UI because either the token field or the username/password
> field are a waste of space.

I think a checkbox for "Use token based auth" or a dropdown for
choosing the Auth type and some nice JS code could avoid from this.

> 
> Actually, we need to work towards having token only. Anything else is
> just dangerous because the whole account can be managed if this data
> leaks.

You are true, but sadly this cannot be done by us - it'ss the job of
the providers out there.

- Stefan

> 
> -Michael
> 
> > On 2 Dec 2020, at 16:02, Stefan Schantl <stefan.schantl(a)ipfire.org>
> > wrote:
> > 
> > Mhm,
> > 
> > you are right this will only move the problem from the developers
> > (us)
> > to the users.
> > 
> > This is a really hard problem because there is no easy solution for
> > this issue.
> > 
> > We simple can take care about the users input and verify if the
> > providers supports what has been configured or we even do not.
> > 
> > If we decide to safe the users from themself, we need something to
> > verify against and that would be something like such a crappy
> > static
> > list.
> > 
> > Do I miss something or think to narrow?
> > 
> > @List followers, what are your opinions?
> > 
> > Best regards,
> > 
> > -Stefan
> > > You are moving the problem from the developer to the user.
> > > 
> > > I think that might be more messy.
> > > 
> > > I am also not sure how this will affect existing setups?
> > > 
> > > -Michael
> > > 
> > > > On 2 Dec 2020, at 15:35, Stefan Schantl <
> > > > stefan.schantl(a)ipfire.org>
> > > > wrote:
> > > > 
> > > > Hello Michael,
> > > > 
> > > > the intension of this patch was, that a supported provider of
> > > > DDNS
> > > > has
> > > > changed it's API to support now token based authentication. The
> > > > code
> > > > already has been changed so here we are safe by now.
> > > > 
> > > > Also in case a new dynamic DNS provider will be added to DDNS,
> > > > we
> > > > do
> > > > not have to do anything, because the GUI automatically will be
> > > > filled
> > > > with the new provider.
> > > > 
> > > > But there is one big exception in this:
> > > > 
> > > > If a new or existing provider has supports authentication
> > > > tokens,
> > > > this
> > > > provider has to be added to this list, which is not very
> > > > intuitive.
> > > > 
> > > > We also have to ship the GUI each time for new, if this
> > > > happened.
> > > > 
> > > > (This was the former reason, why we created the "ddns list-
> > > > providers"
> > > > command to prevent from this.)
> > > > 
> > > > My change simplifies, the check if token based authentication
> > > > should be
> > > > used or not. It removes the check against the static list of
> > > > providers
> > > > which supports token based authentications. (This is the list,
> > > > which
> > > > needs to be keep up to date by hand.)
> > > > 
> > > > For the user nothing changes, because if he speciefies "token"
> > > > as
> > > > username, still the token base auth will be used for the
> > > > choosen
> > > > provider.
> > > > 
> > > > The only way an user may be affected is, if he configures a
> > > > token
> > > > based
> > > > auth for a provider which does not supports it. This now would
> > > > be
> > > > possible and will result in an authentication error against the
> > > > provider - But Hey, if he fills in incorrect data the same will
> > > > be
> > > > happen.
> > > > 
> > > > The only bigger problem would be if the valid username of a
> > > > user is
> > > > "token". In this case he will be affected in the same way and
> > > > this
> > > > could not be fixed in an easy way.
> > > > 
> > > > IMHO, the benefits are bigger for us, because the maintain work
> > > > will
> > > > become much easier and one stupid error source will get
> > > > eliminated.
> > > > 
> > > > Best regards,
> > > > 
> > > > -Stefan 
> > > > > Hello,
> > > > > 
> > > > > I do not understand exactly what this patch is trying to
> > > > > achieve.
> > > > > 
> > > > > Unfortunately we have no choice than doing it this way with
> > > > > the
> > > > > current UI.
> > > > > 
> > > > > I do not think it is worth altering the UI for this, and I do
> > > > > not
> > > > > know how we could do it without having a list again?
> > > > > 
> > > > > -Michael
> > > > > 
> > > > > > On 2 Dec 2020, at 11:30, Stefan Schantl <
> > > > > > stefan.schantl(a)ipfire.org>
> > > > > > wrote:
> > > > > > 
> > > > > > This is really hard to maintain when adding new or altering
> > > > > > existing
> > > > > > providers.
> > > > > > 
> > > > > > Reference #12415.
> > > > > > 
> > > > > > Signed-off-by: Stefan Schantl <stefan.schantl(a)ipfire.org>
> > > > > > ---
> > > > > > html/cgi-bin/ddns.cgi | 8 ++++----
> > > > > > 1 file changed, 4 insertions(+), 4 deletions(-)
> > > > > > 
> > > > > > diff --git a/html/cgi-bin/ddns.cgi b/html/cgi-bin/ddns.cgi
> > > > > > index 715c37290..024eaf7f6 100644
> > > > > > --- a/html/cgi-bin/ddns.cgi
> > > > > > +++ b/html/cgi-bin/ddns.cgi
> > > > > > @@ -665,13 +665,13 @@ sub GenerateDDNSConfigFile {
> > > > > > 
> > > > > > 		my $use_token = 0;
> > > > > > 
> > > > > > -		# Handle token based auth for various
> > > > > > providers.
> > > > > > -		if ($provider ~~ ["dns.lightningwirelabs.com",
> > > > > > "entrydns.net", "regfish.com",
> > > > > > -				  "spdns.de", "zzzz.io"] &&
> > > > > > $username
> > > > > > eq "token") {
> > > > > > +		# Check if token based auth is configured.
> > > > > > +		if ($username eq "token") {
> > > > > > 			$use_token = 1;
> > > > > > +		}
> > > > > > 
> > > > > > 		# Handle token auth for freedns.afraid.org and
> > > > > > regfish.com.
> > > > > > -		} elsif ($provider ~~ ["freedns.afraid.org",
> > > > > > "regfish.com"] && $password eq "") {
> > > > > > +		if ($provider ~~ ["freedns.afraid.org",
> > > > > > "regfish.com"]
> > > > > > && $password eq "") {
> > > > > > 			$use_token = 1;
> > > > > > 			$password = $username;
> > > > > > 
> > > > > > -- 
> > > > > > 2.20.1
> > > > > > 

[[PATCHv2]] Add option to list provider with token support.

[Stefan Schantl]

[-- Attachment #1: Type: text/plain, Size: 9296 bytes --]

This option can be used to get a list of all known provider which support
a token based authentication method.

In order to provide this feature the provider details has been extended
to contain the information if a provider supports this authentication
method or not.

Signed-off-by: Stefan Schantl <stefan.schantl(a)ipfire.org>
---
 ddns.in               |  8 ++++++++
 src/ddns/__init__.py  | 14 ++++++++++++++
 src/ddns/providers.py | 38 ++++++++++++++++++++++++++++++++++++++
 3 files changed, 60 insertions(+)
 mode change 100644 => 100755 ddns.in

diff --git a/ddns.in b/ddns.in
old mode 100644
new mode 100755
index 0e377e7..538e4b0
--- a/ddns.in
+++ b/ddns.in
@@ -49,6 +49,10 @@ def main():
 	p_list_providers = subparsers.add_parser("list-providers",
 		help=_("List all available providers"))
 
+	# list-token-provider
+	p_list_token_provider = subparsers.add_parser("list-token-provider",
+		help=_("List all providers which supports authentication via token"))
+
 	# update
 	p_update = subparsers.add_parser("update", help=_("Update DNS record"))
 	p_update.add_argument("hostname")
@@ -85,6 +89,10 @@ def main():
 		provider_names = d.get_provider_names()
 		print("\n".join(provider_names))
 
+	elif args.subparsers_name == "list-token-providers":
+		token_provider = d.get_provider_with_token_support()
+		print("\n".join(token_provider))
+
 	elif args.subparsers_name == "update":
 		d.updateone(hostname=args.hostname, force=args.force)
 
diff --git a/src/ddns/__init__.py b/src/ddns/__init__.py
index 3e43fa7..ca232bf 100644
--- a/src/ddns/__init__.py
+++ b/src/ddns/__init__.py
@@ -86,6 +86,20 @@ class DDNSCore(object):
 		"""
 		return sorted(self.providers.keys())
 
+	def get_provider_with_token_support(self):
+		"""
+			Returns a list with names of all registered providers
+			which support token based authtentication.
+		"""
+
+		token_provider = []
+
+		for handle, provider in sorted(self.providers.items()):
+			if provider.supports_token_auth is True:
+				token_provider.append(handle)
+
+		return sorted(token_provider)
+
 	def load_configuration(self, filename):
 		logger.debug(_("Loading configuration file %s") % filename)
 
diff --git a/src/ddns/providers.py b/src/ddns/providers.py
index a1ca3f3..b0066d5 100644
--- a/src/ddns/providers.py
+++ b/src/ddns/providers.py
@@ -73,6 +73,10 @@ class DDNSProvider(object):
 	# Required to remove AAAA records if IPv6 is absent again.
 	can_remove_records = True
 
+	# True if the provider supports authentication via a random
+	# generated token instead of username and password.
+	supports_token_auth = True
+
 	@staticmethod
 	def supported():
 		"""
@@ -352,6 +356,10 @@ class DDNSProtocolDynDNS2(object):
 	# The DynDNS protocol version 2 does not allow to remove records
 	can_remove_records = False
 
+	# The DynDNS protocol version 2 only supports authentication via
+	# username and password.
+	supports_token_auth = False
+
 	def prepare_request_data(self, proto):
 		data = {
 			"hostname" : self.hostname,
@@ -440,6 +448,7 @@ class DDNSProviderAllInkl(DDNSProvider):
 
 	url = "http://dyndns.kasserver.com"
 	can_remove_records = False
+	supports_token_auth = False
 
 	def update(self):
 		# There is no additional data required so we directly can
@@ -464,6 +473,8 @@ class DDNSProviderBindNsupdate(DDNSProvider):
 
 	DEFAULT_TTL = 60
 
+	supports_token_auth = False
+
 	@staticmethod
 	def supported():
 		# Search if the nsupdate utility is available
@@ -550,6 +561,7 @@ class DDNSProviderChangeIP(DDNSProvider):
 
 	url = "https://nic.changeip.com/nic/update"
 	can_remove_records = False
+	supports_token_auth = False
 
 	def update_protocol(self, proto):
 		data = {
@@ -616,6 +628,7 @@ class DDNSProviderDDNSS(DDNSProvider):
 
 	url = "http://www.ddnss.de/upd.php"
 	can_remove_records = False
+	supports_token_auth = False
 
 	def update_protocol(self, proto):
 		data = {
@@ -678,6 +691,7 @@ class DDNSProviderDHS(DDNSProvider):
 
 	url = "http://members.dhs.org/nic/hosts"
 	can_remove_records = False
+	supports_token_auth = False
 
 	def update_protocol(self, proto):
 		data = {
@@ -710,6 +724,7 @@ class DDNSProviderDNSpark(DDNSProvider):
 
 	url = "https://control.dnspark.com/api/dynamic/update.php"
 	can_remove_records = False
+	supports_token_auth = False
 
 	def update_protocol(self, proto):
 		data = {
@@ -758,6 +773,7 @@ class DDNSProviderDtDNS(DDNSProvider):
 
 	url = "https://www.dtdns.com/api/autodns.cfm"
 	can_remove_records = False
+	supports_token_auth = False
 
 	def update_protocol(self, proto):
 		data = {
@@ -813,6 +829,7 @@ class DDNSProviderDuckDNS(DDNSProvider):
 
 	url = "https://www.duckdns.org/update"
 	can_remove_records = False
+	supports_token_auth = True
 
 	def update(self):
 		# Raise an error if no auth details are given.
@@ -914,6 +931,7 @@ class DDNSProviderDynUp(DDNSProvider):
 
 	url = "https://dynup.de/dyn.php"
 	can_remove_records = False
+	supports_token_auth = False
 
 	def update_protocol(self, proto):
 		data = {
@@ -979,6 +997,8 @@ class DDNSProviderEasyDNS(DDNSProvider):
 
 	url = "http://api.cp.easydns.com/dyn/tomato.php"
 
+	supports_token_auth = False
+
 	def update_protocol(self, proto):
 		data = {
 			"myip"     : self.get_address(proto, "-"),
@@ -1032,6 +1052,7 @@ class DDNSProviderDynsNet(DDNSProvider):
 	website   = "http://www.dyns.net/"
 	protocols = ("ipv4",)
 	can_remove_records = False
+	supports_token_auth = False
 
 	# There is very detailed informatio about how to send the update request and
 	# the possible response codes. (Currently we are using the v1.1 proto)
@@ -1083,6 +1104,7 @@ class DDNSProviderEnomCom(DDNSResponseParserXML, DDNSProvider):
 
 	url = "https://dynamic.name-services.com/interface.asp"
 	can_remove_records = False
+	supports_token_auth = False
 
 	def update_protocol(self, proto):
 		data = {
@@ -1125,6 +1147,7 @@ class DDNSProviderEntryDNS(DDNSProvider):
 	# here: https://entrydns.net/help
 	url = "https://entrydns.net/records/modify"
 	can_remove_records = False
+	supports_token_auth = True
 
 	def update_protocol(self, proto):
 		data = {
@@ -1165,6 +1188,7 @@ class DDNSProviderFreeDNSAfraidOrg(DDNSProvider):
 	# page. All used values have been collected by testing.
 	url = "https://freedns.afraid.org/dynamic/update.php"
 	can_remove_records = False
+	supports_token_auth = True
 
 	def update_protocol(self, proto):
 		data = {
@@ -1246,6 +1270,7 @@ class DDNSProviderKEYSYSTEMS(DDNSProvider):
 
 	url = "https://dynamicdns.key-systems.net/update.php"
 	can_remove_records = False
+	supports_token_auth = False
 
 	def update_protocol(self, proto):
 		address = self.get_address(proto)
@@ -1297,6 +1322,8 @@ class DDNSProviderLightningWireLabs(DDNSProvider):
 	# Information about the format of the HTTPS request is to be found
 	# https://dns.lightningwirelabs.com/knowledge-base/api/ddns
 
+	supports_token_auth = True
+
 	url = "https://dns.lightningwirelabs.com/update"
 
 	def update(self):
@@ -1365,6 +1392,7 @@ class DDNSProviderNamecheap(DDNSResponseParserXML, DDNSProvider):
 
 	url = "https://dynamicdns.park-your-domain.com/update"
 	can_remove_records = False
+	supports_token_auth = False
 
 	def update_protocol(self, proto):
 		# Namecheap requires the hostname splitted into a host and domain part.
@@ -1458,6 +1486,8 @@ class DDNSProviderNsupdateINFO(DDNSProtocolDynDNS2, DDNSProvider):
 	# has not been implemented here, yet.
 	can_remove_records = False
 
+	supports_token_auth = True
+
 	# After a failed update, there will be no retries
 	# https://bugzilla.ipfire.org/show_bug.cgi?id=10603
 	holdoff_failure_days = None
@@ -1534,6 +1564,7 @@ class DDNSProviderRegfish(DDNSProvider):
 
 	url = "https://dyndns.regfish.de/"
 	can_remove_records = False
+	supports_token_auth = True
 
 	def update(self):
 		data = {
@@ -1630,6 +1661,7 @@ class DDNSProviderServercow(DDNSProvider):
 
 	url = "https://www.servercow.de/dnsupdate/update.php"
 	can_remove_records = False
+	supports_token_auth = False
 
 	def update_protocol(self, proto):
 		data = {
@@ -1671,6 +1703,8 @@ class DDNSProviderSPDNS(DDNSProtocolDynDNS2, DDNSProvider):
 
 	url = "https://update.spdyn.de/nic/update"
 
+	supports_token_auth = True
+
 	@property
 	def username(self):
 		return self.get("username") or self.hostname
@@ -1774,6 +1808,8 @@ class DDNSProviderZoneedit(DDNSProvider):
 	website   = "http://www.zoneedit.com"
 	protocols = ("ipv4",)
 
+	supports_token_auth = False
+
 	# Detailed information about the request and the response codes can be
 	# obtained here:
 	# http://www.zoneedit.com/doc/api/other.html
@@ -1821,6 +1857,7 @@ class DDNSProviderDNSmadeEasy(DDNSProvider):
 
 	url = "https://cp.dnsmadeeasy.com/servlet/updateip?"
 	can_remove_records = False
+	supports_token_auth = False
 
 	def update_protocol(self, proto):
 		data = {
@@ -1871,6 +1908,7 @@ class DDNSProviderZZZZ(DDNSProvider):
 
 	url = "https://zzzz.io/api/v1/update"
 	can_remove_records = False
+	supports_token_auth = True
 
 	def update_protocol(self, proto):
 		data = {
-- 
2.20.1

Re: [PATCH] ddns.cgi: Drop static provider list for token based auth.

[Adolf Belka]

[-- Attachment #1: Type: text/plain, Size: 5101 bytes --]

Hi Stefan,

Would it be possible to create some form of simple database file where all known suppliers are listed in together with what inputs they expect.
Then you would know which items to check for in the WUI. Maybe you could even only show the required input boxes once the supplier has been chosen from the drop-down box.

Regards,

Adolf.


On 02/12/2020 17:02, Stefan Schantl wrote:
> Mhm,
> 
> you are right this will only move the problem from the developers (us)
> to the users.
> 
> This is a really hard problem because there is no easy solution for
> this issue.
> 
> We simple can take care about the users input and verify if the
> providers supports what has been configured or we even do not.
> 
> If we decide to safe the users from themself, we need something to
> verify against and that would be something like such a crappy static
> list.
> 
> Do I miss something or think to narrow?
> 
> @List followers, what are your opinions?
> 
> Best regards,
> 
> -Stefan
>>
>> You are moving the problem from the developer to the user.
>>
>> I think that might be more messy.
>>
>> I am also not sure how this will affect existing setups?
>>
>> -Michael
>>
>>> On 2 Dec 2020, at 15:35, Stefan Schantl <stefan.schantl(a)ipfire.org>
>>> wrote:
>>>
>>> Hello Michael,
>>>
>>> the intension of this patch was, that a supported provider of DDNS
>>> has
>>> changed it's API to support now token based authentication. The
>>> code
>>> already has been changed so here we are safe by now.
>>>
>>> Also in case a new dynamic DNS provider will be added to DDNS, we
>>> do
>>> not have to do anything, because the GUI automatically will be
>>> filled
>>> with the new provider.
>>>
>>> But there is one big exception in this:
>>>
>>> If a new or existing provider has supports authentication tokens,
>>> this
>>> provider has to be added to this list, which is not very intuitive.
>>>
>>> We also have to ship the GUI each time for new, if this happened.
>>>
>>> (This was the former reason, why we created the "ddns list-
>>> providers"
>>> command to prevent from this.)
>>>
>>> My change simplifies, the check if token based authentication
>>> should be
>>> used or not. It removes the check against the static list of
>>> providers
>>> which supports token based authentications. (This is the list,
>>> which
>>> needs to be keep up to date by hand.)
>>>
>>> For the user nothing changes, because if he speciefies "token" as
>>> username, still the token base auth will be used for the choosen
>>> provider.
>>>
>>> The only way an user may be affected is, if he configures a token
>>> based
>>> auth for a provider which does not supports it. This now would be
>>> possible and will result in an authentication error against the
>>> provider - But Hey, if he fills in incorrect data the same will be
>>> happen.
>>>
>>> The only bigger problem would be if the valid username of a user is
>>> "token". In this case he will be affected in the same way and this
>>> could not be fixed in an easy way.
>>>
>>> IMHO, the benefits are bigger for us, because the maintain work
>>> will
>>> become much easier and one stupid error source will get eliminated.
>>>
>>> Best regards,
>>>
>>> -Stefan
>>>> Hello,
>>>>
>>>> I do not understand exactly what this patch is trying to achieve.
>>>>
>>>> Unfortunately we have no choice than doing it this way with the
>>>> current UI.
>>>>
>>>> I do not think it is worth altering the UI for this, and I do not
>>>> know how we could do it without having a list again?
>>>>
>>>> -Michael
>>>>
>>>>> On 2 Dec 2020, at 11:30, Stefan Schantl <
>>>>> stefan.schantl(a)ipfire.org>
>>>>> wrote:
>>>>>
>>>>> This is really hard to maintain when adding new or altering
>>>>> existing
>>>>> providers.
>>>>>
>>>>> Reference #12415.
>>>>>
>>>>> Signed-off-by: Stefan Schantl <stefan.schantl(a)ipfire.org>
>>>>> ---
>>>>> html/cgi-bin/ddns.cgi | 8 ++++----
>>>>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>>>>
>>>>> diff --git a/html/cgi-bin/ddns.cgi b/html/cgi-bin/ddns.cgi
>>>>> index 715c37290..024eaf7f6 100644
>>>>> --- a/html/cgi-bin/ddns.cgi
>>>>> +++ b/html/cgi-bin/ddns.cgi
>>>>> @@ -665,13 +665,13 @@ sub GenerateDDNSConfigFile {
>>>>>
>>>>> 		my $use_token = 0;
>>>>>
>>>>> -		# Handle token based auth for various
>>>>> providers.
>>>>> -		if ($provider ~~ ["dns.lightningwirelabs.com",
>>>>> "entrydns.net", "regfish.com",
>>>>> -				  "spdns.de", "zzzz.io"] &&
>>>>> $username
>>>>> eq "token") {
>>>>> +		# Check if token based auth is configured.
>>>>> +		if ($username eq "token") {
>>>>> 			$use_token = 1;
>>>>> +		}
>>>>>
>>>>> 		# Handle token auth for freedns.afraid.org and
>>>>> regfish.com.
>>>>> -		} elsif ($provider ~~ ["freedns.afraid.org",
>>>>> "regfish.com"] && $password eq "") {
>>>>> +		if ($provider ~~ ["freedns.afraid.org",
>>>>> "regfish.com"]
>>>>> && $password eq "") {
>>>>> 			$use_token = 1;
>>>>> 			$password = $username;
>>>>>
>>>>> -- 
>>>>> 2.20.1
>>>>>

Re: [PATCH] ddns.cgi: Drop static provider list for token based auth.

[Stefan Schantl]

[-- Attachment #1: Type: text/plain, Size: 6273 bytes --]

Hello Adolf,

thanks for joining the conversation and your thoughts.
> Hi Stefan,
> 
> Would it be possible to create some form of simple database file
> where all known suppliers are listed in together with what inputs
> they expect.

Yes of course this would be possible, but would not really solve the
problem of a static list or file which also needs to be adjusted if new
providers will be added or existing ones are changed.

> Then you would know which items to check for in the WUI. Maybe you
> could even only show the required input boxes once the supplier has
> been chosen from the drop-down box.

In my reply to Michael I put some thoughts about how this issue
hopefully can be solved in a very smart way by getting the affected
providers directly from the ddns tool itself.


Best regards,

-Stefan
> 
> Regards,
> 
> Adolf.
> 
> 
> On 02/12/2020 17:02, Stefan Schantl wrote:
> > Mhm,
> > 
> > you are right this will only move the problem from the developers
> > (us)
> > to the users.
> > 
> > This is a really hard problem because there is no easy solution for
> > this issue.
> > 
> > We simple can take care about the users input and verify if the
> > providers supports what has been configured or we even do not.
> > 
> > If we decide to safe the users from themself, we need something to
> > verify against and that would be something like such a crappy
> > static
> > list.
> > 
> > Do I miss something or think to narrow?
> > 
> > @List followers, what are your opinions?
> > 
> > Best regards,
> > 
> > -Stefan
> > > You are moving the problem from the developer to the user.
> > > 
> > > I think that might be more messy.
> > > 
> > > I am also not sure how this will affect existing setups?
> > > 
> > > -Michael
> > > 
> > > > On 2 Dec 2020, at 15:35, Stefan Schantl <
> > > > stefan.schantl(a)ipfire.org>
> > > > wrote:
> > > > 
> > > > Hello Michael,
> > > > 
> > > > the intension of this patch was, that a supported provider of
> > > > DDNS
> > > > has
> > > > changed it's API to support now token based authentication. The
> > > > code
> > > > already has been changed so here we are safe by now.
> > > > 
> > > > Also in case a new dynamic DNS provider will be added to DDNS,
> > > > we
> > > > do
> > > > not have to do anything, because the GUI automatically will be
> > > > filled
> > > > with the new provider.
> > > > 
> > > > But there is one big exception in this:
> > > > 
> > > > If a new or existing provider has supports authentication
> > > > tokens,
> > > > this
> > > > provider has to be added to this list, which is not very
> > > > intuitive.
> > > > 
> > > > We also have to ship the GUI each time for new, if this
> > > > happened.
> > > > 
> > > > (This was the former reason, why we created the "ddns list-
> > > > providers"
> > > > command to prevent from this.)
> > > > 
> > > > My change simplifies, the check if token based authentication
> > > > should be
> > > > used or not. It removes the check against the static list of
> > > > providers
> > > > which supports token based authentications. (This is the list,
> > > > which
> > > > needs to be keep up to date by hand.)
> > > > 
> > > > For the user nothing changes, because if he speciefies "token"
> > > > as
> > > > username, still the token base auth will be used for the
> > > > choosen
> > > > provider.
> > > > 
> > > > The only way an user may be affected is, if he configures a
> > > > token
> > > > based
> > > > auth for a provider which does not supports it. This now would
> > > > be
> > > > possible and will result in an authentication error against the
> > > > provider - But Hey, if he fills in incorrect data the same will
> > > > be
> > > > happen.
> > > > 
> > > > The only bigger problem would be if the valid username of a
> > > > user is
> > > > "token". In this case he will be affected in the same way and
> > > > this
> > > > could not be fixed in an easy way.
> > > > 
> > > > IMHO, the benefits are bigger for us, because the maintain work
> > > > will
> > > > become much easier and one stupid error source will get
> > > > eliminated.
> > > > 
> > > > Best regards,
> > > > 
> > > > -Stefan
> > > > > Hello,
> > > > > 
> > > > > I do not understand exactly what this patch is trying to
> > > > > achieve.
> > > > > 
> > > > > Unfortunately we have no choice than doing it this way with
> > > > > the
> > > > > current UI.
> > > > > 
> > > > > I do not think it is worth altering the UI for this, and I do
> > > > > not
> > > > > know how we could do it without having a list again?
> > > > > 
> > > > > -Michael
> > > > > 
> > > > > > On 2 Dec 2020, at 11:30, Stefan Schantl <
> > > > > > stefan.schantl(a)ipfire.org>
> > > > > > wrote:
> > > > > > 
> > > > > > This is really hard to maintain when adding new or altering
> > > > > > existing
> > > > > > providers.
> > > > > > 
> > > > > > Reference #12415.
> > > > > > 
> > > > > > Signed-off-by: Stefan Schantl <stefan.schantl(a)ipfire.org>
> > > > > > ---
> > > > > > html/cgi-bin/ddns.cgi | 8 ++++----
> > > > > > 1 file changed, 4 insertions(+), 4 deletions(-)
> > > > > > 
> > > > > > diff --git a/html/cgi-bin/ddns.cgi b/html/cgi-bin/ddns.cgi
> > > > > > index 715c37290..024eaf7f6 100644
> > > > > > --- a/html/cgi-bin/ddns.cgi
> > > > > > +++ b/html/cgi-bin/ddns.cgi
> > > > > > @@ -665,13 +665,13 @@ sub GenerateDDNSConfigFile {
> > > > > > 
> > > > > > 		my $use_token = 0;
> > > > > > 
> > > > > > -		# Handle token based auth for various
> > > > > > providers.
> > > > > > -		if ($provider ~~ ["dns.lightningwirelabs.com",
> > > > > > "entrydns.net", "regfish.com",
> > > > > > -				  "spdns.de", "zzzz.io"] &&
> > > > > > $username
> > > > > > eq "token") {
> > > > > > +		# Check if token based auth is configured.
> > > > > > +		if ($username eq "token") {
> > > > > > 			$use_token = 1;
> > > > > > +		}
> > > > > > 
> > > > > > 		# Handle token auth for freedns.afraid.org and
> > > > > > regfish.com.
> > > > > > -		} elsif ($provider ~~ ["freedns.afraid.org",
> > > > > > "regfish.com"] && $password eq "") {
> > > > > > +		if ($provider ~~ ["freedns.afraid.org",
> > > > > > "regfish.com"]
> > > > > > && $password eq "") {
> > > > > > 			$use_token = 1;
> > > > > > 			$password = $username;
> > > > > > 
> > > > > > -- 
> > > > > > 2.20.1
> > > > > >