I’ve updated the project tonight to cover most of the pages rendered with tables and also encoded the path used for the detection to avoid exposing paths of the WUI in the source code.
You can check this post to update your current version.
Now I’m looking for a way to rebase the project so that previous commits with WUI paths will be removed. I searched for the best way to do it with VSCode but a part a confirm dialog that just accept nothing as valid I could not do it… Tried using the git rebase command, nothing…
So I’ll try again tomorrow.
@bonnietwin , Is it long to be added to the dev mailing usually? I still haven’t received anything since I’ve made the subscription so I’m wondering if that’s normal or not
One last thing regarding the last release, I might have missed some pages that contains tables to patch so I’ll setup a VM and test every addons and their related pages to find which ones needs to be patched to be readable when the dark theme is enabled.
It’s usually fairly quick but right now is the holiday season with Christmas and New Year so people will likely be away having a bit of a rest so it would not surprise me if response were slower. All the people supporting this do it in their free time.
If you have not had a response by end of this week, then report back and I will ask at the next devs monthly conf call next week. If you can send me a PM on this forum, giving the details of your subscription request then it can be chased up to see if it has been blocked for some reason.
No worries, that’s what I was thinking about the team being busy or resting for a moment
So no problem, I’ll wait until next week and let you know if I received something or not. I just wanted to do everything you asked me as soon as I can.
In the meantime I’ll keep improving the project and make it ready to be packaged as an addon.
I normally use a Javascript bookmarklet to force any websites to become dark without using any extensions (and so, no privacy risks) but it didn’t rendered nicely on the IPFire WUI so I decided to make something better and if possible, useful for others too.
As promised, I’m implementing another security layer in the project that is called SRI to reduce possibilities to tamper the JS file during the load and so inject malicious code that could then break the security implemented in the WUI.
It’s not bulletproof but it will drastically reduce the risks and make the job much harder for the bad actors as this would require at least the following:
Add malicious code to the JS file during the load
Compute and encode the new checksum of the JS file
Intercept loaded pages to inject the newly computed checksum in the HTML source before it arrive to the client side
So it’s still possible to tamper the file during the load but it makes the job much difficult than without using SRI.
It will also prevent any local changes in the JS file to be loaded without a proper checksum generated, encoded and added to the <script> tag that load the JS file.
If this fictional attacker would have also changed the defined checksum in the <script> tag used to load the JS file, then it would have worked but in this case… It would just mean that your IPFire deployment is already hacked and the attacker can do largely worse than just modifying a JS file…
The same is valid if the attacker is able to intercept the WUI load before it arrive on the victim side, this just means that the attacker is already in the network and so can do much more than just intercepting and tampering WUI requests.
I’ll write here when everything has been released. The next release will also include an update feature included in the install script.
I really hope you can contribute this project back upstream and help the developers to keep the WUI secure. You clearly have the skills required for this job. Regardless, I thank you for all your work. Really wonderful. An happy new year to you as well.
Many thanks again for your appreciation of my work!
I’m definitely interested to contribute to the IPFire project, I’m just waiting to get my subscription to the dev mailing list accepted (but it can also be an issue on my side) and I’ll ask to the devs where I can help.
I might be limited however on the perl part as I rarely used it. The most I did with perl was to read code and nothing more but maybe I can help on the WUI if the devs are okay with that. I just don’t want to bother anyone.
I’m usually someone very discreet and I’m not looking for fame, I just wanted to make something that could be useful for others and I just had the chance to have my work appreciated
I’ll keep improving it on my spare time and write here about every changes and improvements.
Thanks a lot for letting me know about the bug you’ve found. Could you please create a new issue on the project side? So that I can keep this space for announcements, changes or discussions about the project
Btw, I don’t think you did something wrong as you have the selector icon (the sun in this case) injected at the right place but maybe the click handler is not working on your side.
Unfortunately, without knowing more about your environment I have no idea what is not working on your side.
To help me to debug your issue as best as I can, I would need the following mentioned in your issue on the project repo:
Browser: Firefox, Chrome, Chromium, Safari, Edge, Whatever (I don’t need the version number, just to know what you are using to render the page and so loading the JS code)
Error message: It should be printed in the console so I would need you to hit F12, select the console tab and click on the icon to make the error message appearing in the console
JS file version: It should be mentioned as comment at the top of the file. The latest published version on github is 0.3.1.
Normally I should be able to find what’s going wrong on your side using these two things.
As a side note, I wrote and tested everything using Chromium so it should cover every Chromium based browsers like Chrome and Edge and it might also work on Safari as the rendering engine is quite similar but on Firefox… Maybe not
I’ll do some tests with Firefox on my side and see if I can spot something or not.
Anyway thanks a lot for having tried my patch!
As I’m someone privacy respective, I haven’t included any diagnostics or logging features in the code so I have no idea about who is using my work and how many people are using it so I really appreciate that you took the time to tell me that something was not working on your side
I’ve found the issue. Sounds like the issue is related to Firefox. You can still create an issue on the project repo so that I can track it but from what I’ve tested on my side, the click event / toggle logic does not work on Firefox.
I’ll try to fix the issue with vanilla JS but I might have rewrite some part of the code to use jQuery that is already included and loaded by the WUI.
One of the advantage of jQuery is that it cover this kind of “subtleties” (to stay polite ) and kinda ensure that the code will normally work on every browsers which is something that you have write on your own when using vanilla JS as it’s currently the case.
I’ll just ask you some patience, the fix for Firefox will be included in the next release along with the work done on SRI (SubResource Integrity).
Many thanks again for having reported the issue!
The positive thing is that the auto detection logic worked at least and detected that your environment is configured in dark mode and applied the patch automatically, you just can’t put it back to the light (default mode) which is a little annoying.
Btw, here is a workaround that you can use to get it back to the light mode:
Thanks for your quickly response. I didn’t have time to answer you with the tests, and I was thinking of doing them today, but you’ve gone ahead. hahaha.
I have also tried with my Microsoft Edge and the same thing happens. I only use Firefox and sometimes Edge.
I have tried the F12 with the Edge and the same thing happens. Changing the value works, but clicking the appropriate button does nothing.
Thanks for confirming the bug also on Edge. I’ve checked the code last night (could not stop thinking about it) and I think I’ve just been too much lazy on the code that manage this part and I’ll simply rewrite it better and also test under several browsers before saying “It works now!”
I really hope to be able to support the main browsers without having to write tons of exceptions for each of them otherwise I might have to clearly say somewhere that the patch will work only on a limited subset of browsers.
My spare time is quite limited and there will be always some limitations when you patch something that already exist to make it different than when you directly have access to the sources.
So if I can’t find a way to handle most of the browsers using vanilla JS or jQuery, then the last chance/hope might be to have it included as part of the IPFire project and no longer as an external patch.
Gotta have to think about it…
I don’t want to make something that in the end makes the peoples life more complicated.
I suppose that the button issue is the same as what @roberto reported but regarding the white background switch that is visible, it’s unfortunately a side effect of patching existing things.
In other words, it means that the WUI will always load by default as it always be, meaning with white backgrounds.
As the patch is loaded nearly to the end of the page rendering, the transition between white and dark will always be visible.
I’ve tried to make it more smooth by using transitions between colors and backgrounds but it will never fix what you’ve observed. It will just make the switch less “brutal”.
I’ll try to fine tune the patch load and hopefully solve that background switch issue but I can’t promise anything on that due to many technical reasons.
Basically, I must wait for the browser to have rendered all the DOM elements before being able to patch them. This is the reason why you are seeing this background switch between light and dark during the page load.
Anyway, thanks a lot for having tried my work and I hope that the next release will make it more functional on your side too.
Since I have no knowledge of coding, it’s time to ask ChatGPT for js code to auto detect the brower setting of the dark mode setting, because it’s working in google, youtube etc.
It doesn’t and rely on the way the operating system is providing this information. All the websites you’ve mentioned doesn’t switch automatically in dark mode on my side whatever the browser I’m using.
I’ve published a new release on github that includes the following:
Fix for Firefox browser (and hopefully other major browsers too)
SRI check feature (means that the JS file will not be loaded if modified)
Depending on the version you may already have, you can do the following to install the latest version:
With the -u flag: ./patch.sh -u (if it does not work, use the git clone method below)
With git clone:
# Move to the project folder
cd ~/ipfire-dark-theme
# Get the latest version
git pull
# Remove installed version
./patch.sh -r
# Install latest version
./patch.sh
Once you’ve installed this version, installing the next releases should be as simple as running:
cd ~/ipfire-dark-theme ; ./patch.sh -u
@roberto and @xperimental , can you please test it and let me know if this version works on your side?
The next release should include more patching code for the WUI tables.
.
