proxyAuth addon

[mehdi]

@girish this looks lovely !

Suggestions:

• you could (possibly as an option) do like I do in the Transmission custom auth wall, and allow the request if there are BasicAuth credentials. This would allow Transmission to do away with its custom auth thing completely
• for more advanced use, you could allow this to be restricted to certain URLs in the app (again, as an option)

[girish]

@mehdi said in proxyAuth addon:

allow the request if there are BasicAuth credentials

Done (I saw what you did for transmission and did similar) ! https://git.cloudron.io/cloudron/box/-/commit/641704a74107fab7c54220428b7d4df3676f51d1

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