[Feature] Server Side Host Check #19
Comments
|
That actually might be a good idea - I'll definitely try it. |
|
I feel really bad not responding here sooner, but I've been really busy recently, and once when I got to work on this (about a week back) I was getting errors that didn't make sense - turns out it was my local php server at fault that I had up for testing. Anyway, pls try this when you get a chance. I've made the server check really flexible by making it a per-tile setting (just like
The server check would likely only work for urls that are externally accessible (as opposed to Tailscale generated ones, as is the case with most of mine), but I'm open to updating the php function if needed. |
|
Seems to work but seeing some unexpected anomalies with a https & http mix where it's actually inconsistent. I am really not sure what's going on with it and I'm not prepared to think it's an issue with dasherr at this point. Will do more testing. It would be nice if these serverCheck and disableCheck could be set at section and page levels as well. Update: For some reason the widgets aren't working anymore if I'm in https, if I'm in http they work. |
Right now I feel the server check is only good for exceptional use and someone would enable it in select few tiles. If it was more widely usable then I'd also feel this is called for. Though it's possible that my personal setup is what makes me see it that way (nothing open to outside internet, and every machine on Tailscale).
I'm willing to bet that has something to do with mixed content. Maybe if someday I moved the widget processing to php as well, but that day is not today :) |
|
Fair enough! I don't use Tailscale myself, most of the stuff isn't internet accessible but a few are. |
|
Is Glances internet accessible? For me it isn't and server can't access something via php if I give it a Tailscale address or localhost. Though I'm not ruling out the possibility of me mucking something up because of my inexperience with how server side programming works. |
|
No, right now everything I'm doing is intranet. Glances is local only. In theory the php test should work in either case since it is on the same local subnet as Glances. |
|
Next chance I get, I'll create an extremely simple PHP to test if Glances data can be read at the server and then JS can pull that info periodically through there instead of directly - you think that might help solve any CORS/MixedContent related issues? |
|
It should since the PHP function will be essentially acting as a proxy and since Dashrr would presumably be running on the same subnet as Glances it should be fine. I already do monitoring of intranet services this way. (Personally I don't really need Dashrr's checks for that reason but I imagine others might want it to be more flexible but it's really locked down on the web client side - and rightfully so.) |
Check of services is now handled by the host using a small PHP script that receives the URL to connect to and checks not only if it is alive, but also checks its status code or returns 502 as fallback. Check the status code is necessary in many cases, especially related to the container world, since the status code can be used to see if a service is really alive or dead (playing with healthcheckers and small services that perform this task, for example). The checkOnline() function in worker.js has been modified a bit for reuse. I think another approach to implement this feature is to send an identifier to the PHP script that does a read to settings.json to get the URL of the website to check. I think this is a bit more complex, but it only makes sense if the settings.json cannot be modified through the web UI.
An option to have host check done on the server side rather than the browser.
This would be useful for:
This may also be a fix for #16
The text was updated successfully, but these errors were encountered: