Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.


Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Bookmarks
  • Search
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Brand Logo

Cloudron Forum

Apps | Demo | Docs | Install
  1. Cloudron Forum
  2. App Packaging & Development
  3. proxyAuth addon

proxyAuth addon

Scheduled Pinned Locked Moved App Packaging & Development
54 Posts 15 Posters 10.4k Views 15 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • saikarthikS Offline
    saikarthikS Offline
    saikarthik
    wrote on last edited by saikarthik
    #15
    This post is deleted!
    1 Reply Last reply
    0
    • LonkleL Offline
      LonkleL Offline
      Lonkle
      wrote on last edited by
      #16

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

      1 Reply Last reply
      0
      • girishG girish

        Back in the day, we had an "oauth proxy" for apps that didn't support any authentication to put up an auth wall. This was brought up https://forum.cloudron.io/topic/1451/alternative-to-oauth-proxy . We removed that proxy when we removed OAuth support altogether.

        Recently, there is a bunch of apps that require an auth wall including:

        • Prometheus server/alert manager
        • Cloud torrent
        • Transmission
        • Apps like surfer
        • Many of our internal apps

        I have put in this "proxy auth" feature in Cloudron 6. Just have to add it to addons in the manifest like:

        "addons": {
            "proxyAuth": {}
        }
        

        Just like the ldap addon, user can then select which users/groups can authenticate. If the manifest also has optionalSso, then user can choose to let the app have no auth wall altogether.

        When using this feature, two routes are "reserved" - /login and /logout. Some benefits of having this on the platform side (as opposed in the app are):

        • 2FA login
        • Session management in the user's profile page. i.e can logout from apps etc
        • Easier for us to maintain this feature. Currently, this feature has already been re-implemented in the apps using 3 different stacks - nginx/apache/node...

        I took a lot of inspiration from https://github.com/andygock/auth-server and @mehdi's transmission code. So, big thanks to them!

        ? Offline
        ? Offline
        A Former User
        wrote on last edited by A Former User
        #17

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

        girishG 1 Reply Last reply
        0
        • ? 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.

          girishG Offline
          girishG Offline
          girish
          Staff
          wrote on last edited by
          #18

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

          ? 1 Reply Last reply
          2
          • girishG 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.

            ? Offline
            ? Offline
            A Former User
            wrote on last edited by
            #19

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

            girishG 1 Reply Last reply
            0
            • ? A Former User

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

              girishG Offline
              girishG Offline
              girish
              Staff
              wrote on last edited by
              #20

              @atrilahiji I just recently pushed it 🙂

              1 Reply Last reply
              0
              • saikarthikS Offline
                saikarthikS Offline
                saikarthik
                wrote on last edited by
                #21

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

                nebulonN 1 Reply Last reply
                0
                • saikarthikS saikarthik

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

                  nebulonN Offline
                  nebulonN Offline
                  nebulon
                  Staff
                  wrote on last edited by
                  #22

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

                  jimcavoliJ 1 Reply Last reply
                  2
                  • nebulonN nebulon

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

                    jimcavoliJ Offline
                    jimcavoliJ Offline
                    jimcavoli
                    App Dev
                    wrote on last edited by
                    #23

                    @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

                    nebulonN 1 Reply Last reply
                    0
                    • jimcavoliJ 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

                      nebulonN Offline
                      nebulonN Offline
                      nebulon
                      Staff
                      wrote on last edited by
                      #24

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

                      jimcavoliJ 1 Reply Last reply
                      0
                      • nebulonN nebulon

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

                        jimcavoliJ Offline
                        jimcavoliJ Offline
                        jimcavoli
                        App Dev
                        wrote on last edited by
                        #25

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

                        1 Reply Last reply
                        0
                        • saikarthikS Offline
                          saikarthikS Offline
                          saikarthik
                          wrote on last edited by
                          #26

                          @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?

                          girishG 1 Reply Last reply
                          0
                          • saikarthikS 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?

                            girishG Offline
                            girishG Offline
                            girish
                            Staff
                            wrote on last edited by
                            #27

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

                            1 Reply Last reply
                            2
                            • jimcavoliJ Offline
                              jimcavoliJ Offline
                              jimcavoli
                              App Dev
                              wrote on last edited by
                              #28

                              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

                              girishG 1 Reply Last reply
                              3
                              • jimcavoliJ 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

                                girishG Offline
                                girishG Offline
                                girish
                                Staff
                                wrote on last edited by
                                #29

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

                                mehdiM 1 Reply Last reply
                                1
                                • girishG 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.

                                  mehdiM Offline
                                  mehdiM Offline
                                  mehdi
                                  App Dev
                                  wrote on last edited by
                                  #30

                                  @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/"
                                    ]
                                  }
                                  
                                  T 1 Reply Last reply
                                  3
                                  • mehdiM 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/"
                                      ]
                                    }
                                    
                                    T Offline
                                    T Offline
                                    thetomester13
                                    App Dev
                                    wrote on last edited by
                                    #31

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

                                    1 Reply Last reply
                                    1
                                    • jimcavoliJ Offline
                                      jimcavoliJ Offline
                                      jimcavoli
                                      App Dev
                                      wrote on last edited by
                                      #32

                                      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.

                                      girishG 1 Reply Last reply
                                      0
                                      • girishG girish

                                        Back in the day, we had an "oauth proxy" for apps that didn't support any authentication to put up an auth wall. This was brought up https://forum.cloudron.io/topic/1451/alternative-to-oauth-proxy . We removed that proxy when we removed OAuth support altogether.

                                        Recently, there is a bunch of apps that require an auth wall including:

                                        • Prometheus server/alert manager
                                        • Cloud torrent
                                        • Transmission
                                        • Apps like surfer
                                        • Many of our internal apps

                                        I have put in this "proxy auth" feature in Cloudron 6. Just have to add it to addons in the manifest like:

                                        "addons": {
                                            "proxyAuth": {}
                                        }
                                        

                                        Just like the ldap addon, user can then select which users/groups can authenticate. If the manifest also has optionalSso, then user can choose to let the app have no auth wall altogether.

                                        When using this feature, two routes are "reserved" - /login and /logout. Some benefits of having this on the platform side (as opposed in the app are):

                                        • 2FA login
                                        • Session management in the user's profile page. i.e can logout from apps etc
                                        • Easier for us to maintain this feature. Currently, this feature has already been re-implemented in the apps using 3 different stacks - nginx/apache/node...

                                        I took a lot of inspiration from https://github.com/andygock/auth-server and @mehdi's transmission code. So, big thanks to them!

                                        njN Offline
                                        njN Offline
                                        nj
                                        wrote on last edited by
                                        #33

                                        @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

                                        Founder / Coder • My Apps

                                        mehdiM 1 Reply Last reply
                                        0
                                        • njN 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
                                          mehdiM Offline
                                          mehdiM Offline
                                          mehdi
                                          App Dev
                                          wrote on last edited by
                                          #34

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

                                          1 Reply Last reply
                                          0
                                          Reply
                                          • Reply as topic
                                          Log in to reply
                                          • Oldest to Newest
                                          • Newest to Oldest
                                          • Most Votes


                                          • Login

                                          • Don't have an account? Register

                                          • Login or register to search.
                                          • First post
                                            Last post
                                          0
                                          • Categories
                                          • Recent
                                          • Tags
                                          • Popular
                                          • Bookmarks
                                          • Search