proxyAuth addon

[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/"
  ]
}

[thetomester13]

@mehdi I like this solution and its flexibility. It could also be backwards compatible with the currently version - if no paths are specified, everything is auth'ed.

[jimcavoli]

Agree on the default behavior - I imagine it's unlikely that anything more specific than path-level exceptions are unlikely. Perhaps as an extension to the solution that @mehdi suggests, we could extend the existing format of:

{
  "proxyAuth": {
    "path": "/admin" 
  }
}

To take exceptions:

{
  "proxyAuth": {
    "path": "/admin" ,
    "exclude": [
      "/webhook",
      "/
    ]
  }
}

Or with probably over-the-top features, make everything a map of path and exception(s):

{
  "proxyAuth": {
    "paths": {
      "/" : [
        "/webhook",
        "/public"
      ],
      "/admin": []
    }
  }
}

Honestly, I appreciate the minimal-first approach, and I think the middle option of adding a (understood to be auto-wildcarded) array of exclusions is the easier next step. I can't imagine anything that would need the super-complex variant would be something that would or should rely on such a mechanism to secure it.

[nj]

@girish I don't see the 2FA code prompt on the login page of Simple Torrent. Am I missing something?

Some benefits of having this on the platform side (as opposed in the app are):

• 2FA login

[mehdi]

@nj I don't think this is implemented either:

• Session management in the user's profile page. i.e can logout from apps etc

I think @girish just meant that it would be possible to implement this in the future, not that it would be in the first version of proxyAuth.

[girish]

@nj I have logged it here - https://git.cloudron.io/cloudron/box/-/issues/748 . As @mehdi said, it wasn't implemented as part of the first iteration of proxyAuth.

[girish]

@jimcavoli Shall I go with path: "!/webhooks" for now? Will this be enough for n8n ?

[jimcavoli]

@girish Yeah, that would be enough for n8n I think, though if we're going to go that route, I think making paths an array of either path(s) and/or ! paths makes the most sense in general (at least somehow providing for the option of multiple excluded paths)

[girish]

@jimcavoli won't having it plural cause some confusing semantics if you mix ! and no ! paths ? Let me think

[mehdi]

@girish It works for .gitignore files

[girish]

@mehdi great point. I can copy what they do.

[murgero]

@girish Currently I have an app that this does not work on - is there something special I need to do in the app beyond adding the addon to the addon list?

Edit: I am blind I swear - just formatted the JSON incorrectly for the manifest.

[saikarthik]

@girish Hi Girish, what is the status of this? selectively exposing certain paths to public?

[mehdi]

@saikarthik Girish answered here : https://forum.cloudron.io/post/23886

Yes, proxyAuth exclusion is implemented. I only implemented a simple approach with a ! pattern for now (not an array).

[hendrikvl]

I have a question regarding the proxyAuth addon: If I understand it correctly, it has to added to the manifest file and therefore is only suitable for custom apps. How about an option to enable it for apps that have built-in authentication as well?

In my case, I would like to hide the public site of an Shaarli-instance behind the proxyAuth login. Such that authenticated users can browse the public page and I can additionally login using the builtin auth as admin.
I know, that this usecase is somewhat specific and customary, but it is just meant as an example of possible use cases for an proxyAuth-option with the standard apps.

[mehdi]

@hendrikvl I don't use Shaarli, so I don't know about it very well, but in my opinion, the clean way to do this would be to request the upstream project (Shaarli) to allow an option to protect stuff behind its own auth wall, and have 2 types of users, normal & admin. It seems "hacky" to me to solve this usecase with Cloudron's proxyAuth

[girish]

@hendrikvl Currently, proxyAuth is designed for cases where the app has no user management at all. I think if an app already has user support like shaarli, it's best to ask the upstream project to password protect the public page as @mehdi suggests. BTW, if you post a request upstream, please do post the link here.