search

openwrt / luci

LuCI - OpenWrt Configuration Interface
Apache License 2.0
6.12k stars 2.48k forks source link

luci-app-ddns requires user / password for keyauth ddns provider. #3582

Open morzexxx opened 4 years ago

morzexxx commented 4 years ago

When select the afraid.org-keyauth provider the form doesn't change from user/password to just one password in current trunk.

feckert commented 4 years ago

Please tell us your OpenWrt/LuCI version?

morzexxx commented 4 years ago

OpenWrt SNAPSHOT r12001-2fe464a712 / LuCI Master git-20.019.74462-98ba87a running in rpi 4B Снимок

mrjoel commented 4 years ago

I'm also impacted by this, whether by specifying a service or an "update_url" entry that doesn't use username, password, or either it is definitely an irritant to have luci complaining about an otherwise valid configuration. A simple workaround is to just set the username and password fields to "unused" or some other dummy value, but it would be nice to not be required.

lorthirk commented 3 years ago

+1. At least for my provider (dynu.com), username is optional since you can send the domain and the password and their API will match the current user.

m3thm4th commented 2 years ago

luci-app-ddns is utterly broken in OpenWRT 21.02 because of this issue. All the required fields which are actually not to be used make the application unusable. It used to work with no issues in 19.07.

The Path to CA-Certificate field which is added when selecting Use HTTP Secure is also required even though the description states it can be ignored. This field could also be automatically filled as its hint to /etc/ssl/certs.

xorbug commented 2 years ago

I agree, this is tedious the way it is now. I can be wrong as I just gave quick check, but looks like the 21.02 implementation is missing the parsing of the template url and the subsequent filtering of unneeded fields from the settings (and another small thing, the providers dropdown list is not sorted). Afaics, this was being done in 19.07 instead.

But in general, what is the current format used by these json service files now? I mean I can figure it out from the default files in net/ddns-scripts, but is there a generic schema with all possible keys for that json object? If it's not possible already, what about explicitly specifying fields and their attributes (e.g. mandatory/optional) in the service json file itself?

This may be needed because, even if parsing was done (and should already improve the current situation by a lot), there may be some optional field in the url, and labeling a field as required just because of its presence in the url may be undesired. E.g. consider an url containing the [DOMAIN] field: the simplest approach would then assume that it is a required field after parsing (so would probably be set for non-empty validation at least), but that same provider could work just fine without it, maybe deriving it from the token. So it could as well be optional, and actually should be.

Having an additional section which specifies fields and attributes would make parsing the url superfluous and might help building a more effective settings form. On the other hand, it probably requires a more deep knowledge of each service... just some thoughts...

m3thm4th commented 2 years ago

According to this in case of an unused field a random character should be used [NOT used. Set to a character of your choice, because LuCI does not accept empty field]

mrjoel commented 2 years ago

According to this in case of an unused field a random character should be used [NOT used. Set to a character of your choice, because LuCI does not accept empty field]

Sure, that's what I was referencing previously with "A simple workaround is to just set the username and password fields to "unused" or some other dummy value". It works but it's a workaround nonetheless and would be a much nicer UX to not have to put in an unused dummy value.

sirweazel commented 1 year ago

I'm curious how some of you have this configured. I also have DYNU has my ddns, but i hit a few blocks trying to setup. i had it working at one point (but it would only update 1 domain). Now i don't think i have it working at all. I was trying to get the dynu groups to work so one update would update them all? I was trying to get it to work with the generated pasword but i must have been dong something wrong. If someone could post a screenshot with the sensitve parts redacted/changed, that would help a lot. It sounds like some of you have it working by using made up values in some places? Thanks for any help, i know this is a old topic, but it looks like the info is still relevant today.