proxyAuth addon

[ei8fdb]

@nebulon said in What's coming in 6.0 (take 2):

Alternately, we could certainly add a login screen served up with some kind of session. The question then, as already mentioned, is how to logout. We could provide the app with a logout link, still that needs patching the app to some extent.

As I understand it, these are personal media apps, right? Is there therefore a need to logout?

What would happen if a user was able to login, but not log-out? They could close the browser window?

[girish]

@ei8fdb I moved your comment to this topic. I think the auth wall applies to all apps which don't have a notion of user management. For example, apps like prometheus etc as well.

[ei8fdb]

@girish Gotcha.

OK. I've used 2 apps that (I think) don't have user management natively - youtube-del and surfer files app. Is that right?

[girish]

@ei8fdb Indeed, other apps are transmissions, cloud torrent. They can all use this addon.

[fbartels]

@ei8fdb said in proxyAuth addon:

surfer

Surfer has auth for it's backend

[saikarthik]

This post is deleted!

[Lonkle]

Heck, I'd probably switch to this option if my app didn't need to use LDAP to also grab an access token to get permission to restart and repair apps on-demand (if it doesn't already have an app access token, that is).

[A Former User]

@girish I have a request/question. How tedious would it be to incorporate a way to allow customization of the plugin to specify which routes should be protected in the app? For example, if someone wanted to make a cloudron specific app for personal use, would it be possible to allow this plugin to do the heavy lifting in terms of auth and protect routes like /admin, for instance.

What I invision is basically the following use cases:

• an empty list of routes -> all routes are protected
• a list of routes is provided -> only the specified routes are protected

I think this could be a game changer for using Cloudron for business apps or people building out their dev stack entirely on Cloudron without compromising the simplicity of the feature.

Example:

proxyAuth: {
    routes: [
        'admin',
        'profile'
    ],
}

EDIT: Also, this just came to my mind: can apps using this plugin access the LDAP info like name, email, etc? I realize I am probably your worst nightmare with these requests but just thought I'd try.

[girish]

@atrilahiji said in proxyAuth addon:

How tedious would it be to incorporate a way to allow customization of the plugin to specify which routes should be protected in the app

Currently, up to 1 route can be protected - https://docs.cloudron.io/custom-apps/addons/#proxyauth . So, it's basically what you are asking for except that only one route can be protected.

Also, this just came to my mind: can apps using this plugin access the LDAP info like name, email, etc?

I guess we have to make up some HTTP headers to pass on this info like X-REMOTE-USER or something.

[A Former User]

@girish Wow I totally didn't realize there were docs for it. Sorry for bugging you!

[girish]

@atrilahiji I just recently pushed it

[saikarthik]

@girish is there a way to get the username/email from within the app?

[nebulon]

@saikarthik currently not, I guess the only option would be to add the username/email as a header in the requests?

[jimcavoli]

@nebulon That would seem a sensible approach. Similar to other gateway authentication solutions I've seen. Definitely would need to restrict trust of those headers either in app or sever configuration though to prevent escalation/impersonation/ato attacks

[nebulon]

@jimcavoli is there any risk or impersonation angle, if the reverse proxy always explicitly overwrites that header?

[jimcavoli]

@nebulon Yes, an always-overwrite would mitigate as well, as long as the edges get tested well, might be the easier solution

[saikarthik]

@nebulon @girish is this something that can be added to cloudron? passing logged in username/email ID to apps through the header? Any comments/issues?

[girish]

@saikarthik yup, can surely be added. probably next release.

[jimcavoli]

Related: while re-working the n8n packaging, I happened upon what would probably be reasonably common, where there are selected sub-paths of / which should not be authenticated - example being we want / to require auth, but not /webhook/* paths. It's at least non-obvious if not unsupported by the current docs on how to do this with proxyAuth

[girish]

@jimcavoli Indeed, that's not something I designed for. How complicated can these rules get ? Atleast, https://docs.n8n.io/reference/security.html does not seems to have any more information. Or should I just add a publicPath property (singular) and that's enough ? I like to under-design these things and extend them as use cases come.