Enhancement: Include user session cookies when performing monitor requests

[2q2code]

At present, all monitor requests are performed on the server-side. It may be beneficial to do this from the client side, as it would automatically handle inclusion of user session cookies for secure services.

I secure most of my services behind Authelia, so that means that most of the time, the response for the monitor widget is "Unauthorised". Even if I am logged in on the client browser. I have considered other options for this - perhaps allowing access to each site's favicon unrestricted - but not all sites have a usable favicon, either.

Might need to turn this into a discussion?

[svilenmarkov]

alt-status-codes was implemented in #240 for this exact reason. It's not out yet, but it should work in your case since a 401 is technically a "working state" and you'd still be able to catch when a service goes down. Alternatively, there will also be #261 as an option so you wouldn't need to deal with HTTP requests.

[2q2code]

Well, in this case, a 401 is no indication of the site working, as the authentication site runs seperate from the underlying destination site. The authentication portal may be up and running but the site it protects may be down. I will check what 261 is about. On Jan 27, 2025 2:34 AM, from Svilen Markov alt-status-codes was implemented in #240 for this exact reason. It's not out yet, but it should work in your case since a 401 is technically a "working state" and you'd still be able to catch when a service goes down. Alternatively, there will also be #261 as an option so you wouldn't need to deal with HTTP requests. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>

[2q2code]

261 may be helpful for monitoring docker services but not all my services run through docker. Additionally, I prefer to monitor the end-to-end site access. All my sites and services are set up through reverse proxy -> authentication -> target, and I access them this way. On Jan 27, 2025 2:34 AM, from Svilen Markov alt-status-codes was implemented in #240 for this exact reason. It's not out yet, but it should work in your case since a 401 is technically a "working state" and you'd still be able to catch when a service goes down. Alternatively, there will also be #261 as an option so you wouldn't need to deal with HTTP requests. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>