-
-
Notifications
You must be signed in to change notification settings - Fork 566
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix TypeError if no extended DNS error is available #1862
Conversation
Not sure why you think the DietPi version has anything to do with it? 😄 Or do you mean the Pi-hole (AdminLTE) development version? Not sure at all, I think we need someone with more knowledge about where/how the EDE data is retrieved and handled, and how it could be missing in your case. |
pihole dev whoops |
I mean you could try to revert to master branch: pihole checkout master |
i mean yeah that'd fix it but i like being on the dev branch - just picking this to fix it isn't hard :) |
That is actually the important hint. The DNSSEC reply type does not exist in the master branch yet, it was added here: fb2b87e Then the code to show these EDE, which causes this error, was added here: a120e72 @DL6ER And @timocapa is DNSSEC indeed disabled in your case? Just out of curiosity, could you try to enable DNSSEC then, revert the fix and see if the error is still present? |
Thought you picked up on that when you couldn't find the line and I had sent it in the dev branch, with the commit
I do have DNSSEC enabled IIRC |
There is no automated testing for the web interface and I don't think it'd be very meaningful to start adding them now given that the web interface is going to be largely rewritten for v6.0 (to remove PHP under the hood) and possibly replaced by a better framework altogether at a later point in time. |
Ah lol, this is the reason why I didn't see it, I missed the fact that I had a look into the master branch while you gave a link to the devel branch 😄. Okay, then the mystery is solved why this was no error before.
Then we still don't know in which case the value is set and in which case not. However, the fix makes sense regardless. If there is some DNSSEC status missing unexpectedly, then its better to investigate that separately than having a failing query log GUI.
Makes sense. |
Just double checked with the change reverted, doesn't load with either DNSSEC on or off |
Hmm, the prettier check still fails. Can the the npm test be changed so that it prints the full prettier output to the workflow console, rather than into a log file? |
|
I have no Node on the system where the Git push was coming from. I'll try it on another system tomorrow. |
var replyid = parseInt(data[5], 10);
// DNSSEC status
var dnssecStatus;
- var ede = data[11] ? data[11] : '';
+ var ede = data[11] ? data[11] : "";
switch (data[6]) {
case "1":
dnssecStatus = '<br><span class="text-green">SECURE'; |
Also... not much use. e.g:
Further reading prettier/prettier#6885.. but the answer pretty much seems to be "just run prettier before you commit" 😏 |
If no extended DNS errors are available, the "ede" variable is assigned an undefined array value, hence "ede" is undefined. Since the length method is not available on undefined variables, a TypeError is thrown later in the script, which breaks the DNS queries view in the admin panel. This commit solves the issue by assigning an empty string, if no EDE is available (data[11] is undefined). Signed-off-by: MichaIng <[email protected]>
Lol, seems like a discussion with hardened front lines over there 😄. Main developers of course will have a development system and IDE to efficiently develop and commit. It is the spare time contributors to different projects with different programming languages, different frameworks and different CI stacks, like me, which have an easier life when CI checks print the errors. Okay now pettier should be pretty happy 🙂. |
@XhmikosR could we have |
Probably... It needs some changes.
Unsure if this will work with forks and PRs, though. The current situation is not just a big deal IMHO. I mean, if one decides to contribute, they should do it properly locally or after the CI complains. Just my 2 cents. |
Thanks, I can see both worlds. Maybe write flag and then show a diff on the CI. Would be a compromise that should work for all. I'll try to allocate some time to look into this (in a separate PR, obviously). |
I know such case from Nextcloud, a compile bot action which listens on post commands, and compiles, commits (optionally amends) JS based on changed framework modules/sources. The PR checks do compiling as well and show a list file changed/added/removed files, in case, so maintainers can trigger the bot. But this may not work for PRs from forks, even with "allow maintainer edits" enabled, as access for maintainers is usually limited to changed files and GitHub website/clients. Let me know if I should post some sources for action/bot. |
This pull request has been mentioned on Pi-hole Userspace. There might be relevant details there: https://discourse.pi-hole.net/t/pi-hole-ftl-v5-9-web-v5-6-and-core-v5-4-released/49544/1 |
By submitting this pull request, I confirm the following:
{please fill any appropriate checkboxes, e.g: [X]}
{Please ensure that your pull request is for the 'devel' branch!}
git rebase
)git commit --signoff
)What does this PR aim to accomplish?:
If no extended DNS errors are available, the "ede" variable is assigned an undefined array value, hence "ede" is undefined. Since the
length
method is not available on undefined variables, a TypeError is thrown later in the script, which breaks the DNS queries view in the admin panel. It hence needs to be assured that.length
is never called on an undefined variable.How does this PR accomplish the above?:
This commit solves the issue by assigning an empty string, if no EDE is available (
data[11]
is undefined), which seems to be the easier way, compared to changing all cases whereede.length
is called. This way, theede.length > 0
checks keep returning false, if no data was passed.What documentation changes (if any) are needed to support this PR?:
None
For reference: MichaIng/DietPi#4573 (comment)
Issue was observed on Debian Bullseye. But since this is JavaScript, executed in the browser, we're wondering if or why this did not appear before on Buster. Probably something on Bullseye is the reason why no extended DNS errors data is passed in the first place? However, preventing this possible TypeError is a good thing regardless.