allow protocol to always override ssl in geturl() #482
Conversation
Signed-off-by: Matthew Ogilvie <mmogilvi+ddc@zoho.com>
|
Background: I have long used the "use=web" option to extract my IP address from my router with my own config (to avoid guessing which if any "fw" might work, and to avoid offloading anything to free services I don't absolutely have to), but a recent OS update (gentoo) to ddclient 3.10.0 seems to have changed things so the global ssl option is now honored when looking up IP address via web, and not only is it honored, it also takes precedence over an explicitly-specified "web=http://..." (non-https) prefix. Perhaps I could try disabling the global ssl option instead of patching the code, but I suspect that isn't a good idea unless there is some other way to ensure dyndns2 uses ssl. Or is SSL unconditionally part of dyndns2? (I tried prefixing the dyndns2 part to "server=https://..." to override a lack of global "ssl=yes", but that didn't work, and I didn't find any documented technique at all.) FUTURE: I haven't confirmed, but I would guess some of the "fw" options probably may have similar problems, although I haven't fully traced through the code to be sure. FUTURE: It might be better to have a clear way to indicate SSL/non-SSL for every individual kind of internet interaction (including "protocol=dyndns2"), and deprecate the global "ssl" option. |
|
The idea is that forcessl enforces ssl everywhere and ssl should only load/use it by default.
There are no resources to implement this. |
| ## canonify use_ssl, proxy and url | ||
| if ($url =~ /^https:/) { | ||
| $use_ssl = 1; | ||
| } elsif ($url =~ /^http:/) { | ||
| $use_ssl = 0; | ||
| } elsif ($globals{'ssl'} && !($params{ignore_ssl_option} // 0)) { | ||
| $use_ssl = 1; | ||
| } else { | ||
| $use_ssl = 0; | ||
| } |
There was a problem hiding this comment.
Please keep forcessl to always use ssl no matter what the URL says.
There was a problem hiding this comment.
The idea is that forcessl enforces ssl everywhere and ssl should only load/use it by default.
Please keep forcessl to always use ssl no matter what the URL says.
Huh? forcessl local variable was only ever set based on the URL in the first place! (Old lines 2436 and 2437). Were you maybe misreading the old code and thinking it was based on a global option or something? Or am I somehow blind to something else? (Or maybe you didn't notice the second "chunk" of the patch that simplifies the later part of the function to only read (not write) "use_ssl", since github seems to confusingly "collapse" that part of the patch by default for some reason?)
My replacement lines 2436 and 2437 get rid of the separate variable and is functionally identical to how forcessl was used, as the first/highest priority part of a consolidated chain of prioritized elseif's that ONLY decides whether to to use SSL or not, instead of scattering and intermingling the "use SSL" decision logic across multiple places in the function. Seems clearer than the old code to me, but I don't really care as long there is SOME way I can configure it the way I want (no SSL getting IP address from my router on my LAN, but use SSL for anything else ddclient does, such as the actual ddns registration). If you would prefer I code the same logic some other way, I would need to know more about what you are thinking.
(I haven't investigated the registration part carefully, but my impression is that the ddns registration can be SSL, but the only way to do it is with the global "ssl" option, leaving it necessary to use some other technique to disable SSL for IP lookup? Or is there something incorrect in my impressions as described?)
There was a problem hiding this comment.
Were you maybe misreading the old code and thinking it was based on a global option or something?
yeah, thought it was a global option.
Seems clearer than the old code to me, but I don't really care as long there is SOME way I can configure it the way I want (no SSL getting IP address from my router on my LAN, but use SSL for anything else ddclient does, such as the actual ddns registration).
That behaviors is abused in multiple places to enforce https. I don't want to change that and don't have the time to fix it properly.
If you would prefer I code the same logic some other way, I would need to know more about what you are thinking.
I didn't think to much about it and with the limited time I spend on ddclient.
Signed-off-by: Matthew Ogilvie mmogilvi+ddc@zoho.com