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. Feature Requests
  3. Simple auth (e.g. htaccess) for apps without authentication

Simple auth (e.g. htaccess) for apps without authentication

Scheduled Pinned Locked Moved Feature Requests
9 Posts 3 Posters 1.2k Views 3 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.
    • necrevistonnezrN Offline
      necrevistonnezrN Offline
      necrevistonnezr
      wrote on last edited by
      #1

      Is it possible (or already doable) to add a simple auth option for all apps that don't have a built-in authentification?

      I'm thinking of SearxNG, Invidious, etc. where I don't want them completely in the open to (ab)use for everyone.

      Maybe just a simple .htaccess would be enough, so that you had a https://user:password@search.domain.com? Or is there a better method?

      1 Reply Last reply
      0
      • girishG Offline
        girishG Offline
        girish
        Staff
        wrote on last edited by
        #2

        We have the proxyAuth addon for exactly this . It puts an auth wall in front of apps. Depending on the app, this auth well might break extensions, api calls etc. For this reason, this is not a generic option but something we add in the package considering each app.

        Also, it's quite confusing to add auth walls in front of apps that already have a login system. For example, invidivious already has users and login, now we have a totally different auth in front of this. For invidious, private instance feature is being implemented - https://github.com/iv-org/invidious/pull/4259

        necrevistonnezrN 1 Reply Last reply
        1
        • girishG Offline
          girishG Offline
          girish
          Staff
          wrote on last edited by
          #3

          The .htaccess only works in Apache btw and thus limited to apps that use apache (mostly php then).

          Invidious is written in a fancy language (to me anyway) called crystal 🙂 I think searx is python.

          1 Reply Last reply
          0
          • girishG girish

            We have the proxyAuth addon for exactly this . It puts an auth wall in front of apps. Depending on the app, this auth well might break extensions, api calls etc. For this reason, this is not a generic option but something we add in the package considering each app.

            Also, it's quite confusing to add auth walls in front of apps that already have a login system. For example, invidivious already has users and login, now we have a totally different auth in front of this. For invidious, private instance feature is being implemented - https://github.com/iv-org/invidious/pull/4259

            necrevistonnezrN Offline
            necrevistonnezrN Offline
            necrevistonnezr
            wrote on last edited by
            #4

            @girish said in Simple auth (e.g. htaccess) for apps without authentication:

            We have the proxyAuth addon for exactly this . It puts an auth wall in front of apps. Depending on the app, this auth well might break extensions, api calls etc. For this reason, this is not a generic option but something we add in the package considering each app.

            Well, if I understand correctly, the App that's being proxied is still "unprotected", correct?

            If I point proxy.domain.com to app.domain.com or 93.###.###.###, then app.domain.com (or the IP) can still be opened without any authentification (if someone knows or finds out the app.domain.com address, which is usually trivial), can't it? And from the docs I understand that I can't point it to an internal, unpublished IP like 192.168.1.100:88, correct? (<-- This would be awesome, by the way....)

            I think that's the main difference for something like the .htaccess approach (which I understand would only work in an Apache setup).

            girishG 2 Replies Last reply
            0
            • necrevistonnezrN necrevistonnezr

              @girish said in Simple auth (e.g. htaccess) for apps without authentication:

              We have the proxyAuth addon for exactly this . It puts an auth wall in front of apps. Depending on the app, this auth well might break extensions, api calls etc. For this reason, this is not a generic option but something we add in the package considering each app.

              Well, if I understand correctly, the App that's being proxied is still "unprotected", correct?

              If I point proxy.domain.com to app.domain.com or 93.###.###.###, then app.domain.com (or the IP) can still be opened without any authentification (if someone knows or finds out the app.domain.com address, which is usually trivial), can't it? And from the docs I understand that I can't point it to an internal, unpublished IP like 192.168.1.100:88, correct? (<-- This would be awesome, by the way....)

              I think that's the main difference for something like the .htaccess approach (which I understand would only work in an Apache setup).

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

              @necrevistonnezr I was referring to the proxyAuth addon (https://docs.cloudron.io/packaging/addons/#proxyauth) and not the similary named App Proxy .

              proxyAuth - we add this in an app's package. In this, there is no DNS entry for the app itself. Just for the external facing proxy. I guess quite similar to what you have in mind for .htaccess. For example, apps like haste, tldraw, transmission, firefly etc use this already. You will see an authwall in the front (a login screen) to access the app.

              With App Proxy, you are correct, app.domain.com will still be open to internet. One has to protect this using a network firewall.

              1 Reply Last reply
              0
              • necrevistonnezrN necrevistonnezr

                @girish said in Simple auth (e.g. htaccess) for apps without authentication:

                We have the proxyAuth addon for exactly this . It puts an auth wall in front of apps. Depending on the app, this auth well might break extensions, api calls etc. For this reason, this is not a generic option but something we add in the package considering each app.

                Well, if I understand correctly, the App that's being proxied is still "unprotected", correct?

                If I point proxy.domain.com to app.domain.com or 93.###.###.###, then app.domain.com (or the IP) can still be opened without any authentification (if someone knows or finds out the app.domain.com address, which is usually trivial), can't it? And from the docs I understand that I can't point it to an internal, unpublished IP like 192.168.1.100:88, correct? (<-- This would be awesome, by the way....)

                I think that's the main difference for something like the .htaccess approach (which I understand would only work in an Apache setup).

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

                @necrevistonnezr your note on things being public was good, I put a note in the App Proxy docs 🙂

                necrevistonnezrN 1 Reply Last reply
                0
                • girishG girish

                  @necrevistonnezr your note on things being public was good, I put a note in the App Proxy docs 🙂

                  necrevistonnezrN Offline
                  necrevistonnezrN Offline
                  necrevistonnezr
                  wrote on last edited by necrevistonnezr
                  #7

                  @girish Thanks for the clarification - so it's nothing I can apply as a user after app packaging.
                  So in general, my feature request still stands 🙂

                  girishG robiR 2 Replies Last reply
                  0
                  • necrevistonnezrN necrevistonnezr

                    @girish Thanks for the clarification - so it's nothing I can apply as a user after app packaging.
                    So in general, my feature request still stands 🙂

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

                    @necrevistonnezr if you can raise the request for specific apps, we can discuss why or why not we can do it for the app. maybe that's a good was forward here?

                    1 Reply Last reply
                    0
                    • necrevistonnezrN necrevistonnezr

                      @girish Thanks for the clarification - so it's nothing I can apply as a user after app packaging.
                      So in general, my feature request still stands 🙂

                      robiR Offline
                      robiR Offline
                      robi
                      wrote on last edited by
                      #9

                      @necrevistonnezr maybe if it's a simple enough app, you can package it along with the Surfer app which can provide the basic auth w/ a nice config interface.

                      Conscious tech

                      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