proxyAuth addon

[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.

[mehdi]

@girish I think the best would be to have the path in proxyAuth be an array, where given paths can be either positive or negative. It's the way things like .gitignore work.

For example, in this case, it would be:

{
  "proxyAuth": [
    "/",
    "!/webbooks/"
  ]
}