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.0k 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
      #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
                                • girishG Offline
                                  girishG Offline
                                  girish
                                  Staff
                                  wrote on last edited by
                                  #35

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

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

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

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

                                    jimcavoliJ 1 Reply Last reply
                                    0
                                    • girishG girish

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

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

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

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

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

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

                                        mehdiM saikarthikS 2 Replies Last reply
                                        0
                                        • girishG girish

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

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

                                          @girish It works for .gitignore files 🤷

                                          girishG 1 Reply Last reply
                                          1
                                          • mehdiM mehdi

                                            @girish It works for .gitignore files 🤷

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

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

                                            murgeroM 1 Reply Last reply
                                            1
                                            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