HTTP Authentication for Kuma

[fiwand]

Kuma only supports a single admin user account, but provides two features for team/public access:

• the ability to create a public dashboard
• the option to completely disable Kuma's authentication

We'd like to use the public dashboard feature as an internal dashboard, but cannot currently do so because our Cloudron instance is public-facing.

Is there a way to add an optional HTTP authentication layer to the Kuma Cloudron app? A single set of credentials would be perfectly fine for our use case, but we're also OK if other authentication requirements, like being a cloudron user, would make an integration easier or more versatile. We also don't need the authentication to only target specific paths.

Thanks!

[robi]

@fiwand Check to see if Kuma uses Apache and manually modify the .htaccess file.

[fbartels]

@robi it doen't btw https://git.cloudron.io/cloudron/uptime-kuma-app/-/blob/master/start.sh

Maybe one can mod the app to use https://docs.cloudron.io/packaging/addons/#proxyauth.

[robi]

@fbartels or a separate custom nginx config for the kuma subdomain that does it in addition to the default route.

[wind.gmbh]

This is probably related to a feature request I have made a couple of weeks ago:

[girish]

I think we have to implement some app level access level control as @wind-gmbh suggested.

[robi]

@girish said in HTTP Authentication for Kuma:

I think we have to implement some app level access level control as @wind-gmbh suggested.

Agreed, a general Cloudron LDAP + unique pw for different occasions changeable in the UI, per app would be very useful.

[matbrgz]

Hey, take a look at https://github.com/louislam/uptime-kuma/issues/1756#issuecomment-1158597816 they use HTTP Authentication.

Currently, is there any solution for it?

[girish]

@matbrgz I think that ends up protected all of uptime kuma and not just the status page . But of course, one can always tinker the configs in such a way that only specific pages are protected (one has to also investigate protecting API requests to the backend etc). I think this has to be implemented in uptime kuma itself to be fixed reliably.