proxyAuth addon
-
@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?
-
This post is deleted!
-
@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.
-
@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.
-
@girish is there a way to get the username/email from within the app?
-
@saikarthik currently not, I guess the only option would be to add the username/email as a header in the requests?
-
@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
-
@saikarthik yup, can surely be added. probably next release.
-
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 withproxyAuth
-
@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.