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


  • Categories
  • Recent
  • Tags
  • Popular
  • Bookmarks
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

Cloudron Forum

Apps | Demo | Docs | Install

Feat: Only allow authenticated users

Scheduled Pinned Locked Moved Solved Surfer
26 Posts 5 Posters 927 Views
    • 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.
  • fbartelsF Offline
    fbartelsF Offline
    fbartels App Dev
    wrote on last edited by
    #1

    I'd like to host a non public website inside of Surfer. I did make a small test with the new proxy auth feature, but surfer does not seem to be compatible with it (going to /_admin gives a javascript error).

    It would be great if Surfer could be extended to only allow logged in users.

    robiR 1 Reply Last reply
    2
  • robiR Offline
    robiR Offline
    robi
    replied to fbartels on last edited by
    #2

    @fbartels any other way to pw protect the content in surfer?

    Life of sky tech

    fbartelsF 1 Reply Last reply
    0
  • fbartelsF Offline
    fbartelsF Offline
    fbartels App Dev
    replied to robi on last edited by
    #3

    @robi not that I know of

    1 Reply Last reply
    0
  • nebulonN Offline
    nebulonN Offline
    nebulon Staff
    wrote on last edited by
    #4

    Proxy auth is probably not the right solution. I can see how to add such a auth wall optionally, should not be too hard.

    1 Reply Last reply
    4
  • nebulonN Offline
    nebulonN Offline
    nebulon Staff
    wrote on last edited by
    #5

    I guess this is mostly the same as https://git.cloudron.io/cloudron/surfer/-/issues/7

    fbartelsF 1 Reply Last reply
    0
  • fbartelsF Offline
    fbartelsF Offline
    fbartels App Dev
    replied to nebulon on last edited by fbartels
    #6

    @nebulon yes, although I was more thinking about using a Cloudron user to login, instead of setting up a dedicated password for the site.

    1 Reply Last reply
    0
  • nebulonN Offline
    nebulonN Offline
    nebulon Staff
    wrote on last edited by
    #7

    I have started to implement some access restriction with both options, a password or user login. However this would be for the whole website, so you can't protect for example one file or a subfolder.

    fbartelsF 1 Reply Last reply
    1
  • fbartelsF Offline
    fbartelsF Offline
    fbartels App Dev
    replied to nebulon on last edited by
    #8

    @nebulon yes I looked through the commit attached to the Gitlab issue, but was not quite sure about the username/password thing. And as the linked Gitlab issue was just talking about a single password I wanted to mention it again.

    Protecting the whole side is exactly what my use case would be.

    1 Reply Last reply
    0
  • nebulonN Offline
    nebulonN Offline
    nebulon Staff
    wrote on last edited by
    #9

    Yes the user login will get regular Cloudron ldap support there. For the password, I would have some question, maybe someone has an opinion on this.
    Should that shared password we stored hashed on the server or not? Hashing it seems to be the sensible thing to do, however that makes it impossible to show the password back to the admin at a later time if need be, which means if he/she forgot it, resetting it would lock out any other users of that shared secret. On the other hand that password would be part of the backup, which again means it should probably be hashed...

    T 1 Reply Last reply
    0
  • T Offline
    T Offline
    thetomester13 App Dev
    replied to nebulon on last edited by
    #10

    @nebulon my first thought says hashed. If the admin were to forget it, they could simply create a new hashed password and set it and distribute it again to their users. Maybe not ideal but I would personally err on the side of security.

    robiR 1 Reply Last reply
    1
  • robiR Offline
    robiR Offline
    robi
    replied to thetomester13 on last edited by
    #11

    @thetomester13 if the admin forgets it, all he has to do is ask any user, it's the same pw.

    Life of sky tech

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

    If it's a single password, how does "logout" work? I wonder how other password protected sites work. I guess the session just expires after some time and user has to provide password again?

    1 Reply Last reply
    0
  • nebulonN Offline
    nebulonN Offline
    nebulon Staff
    wrote on last edited by
    #13

    Currently I don't intend to have any actionable logout, since the site which will be served up will be from the user and I don't want to inject some magic javascript there with a logout button I guess. So the session will eventually expire and I wanted to invalidate all sessions once the password changes.

    1 Reply Last reply
    1
  • nebulonN Offline
    nebulonN Offline
    nebulon Staff
    wrote on last edited by
    #14

    This is fixed with the published version 5.13.2 now.

    The password is salted and hashed on the server and any change to the access restriction will also result in sessions getting invalidating, forcing users to re-login.

    fbartelsF 1 Reply Last reply
    2
  • fbartelsF Offline
    fbartelsF Offline
    fbartels App Dev
    replied to nebulon on last edited by fbartels
    #15

    hmm.. at least the auth with username & password does not yet seem to work properly. Even if I choose "user restricted" in the settings inside of Surfer I only get a single password prompt when opening the page in an incognito session.

    I had also some problems with the new site title and favicon settings which were introduced in the version before (but I only got to play with now):

    • setting an svg or maybe a too large icon does not properly store settings
      • I originally wanted to set https://github.com/bastienwirtz/homer/blob/main/public/assets/icons/icon-any.svg, but after submitting the form and going back to it, it did not show my custom title and only showed a broken image instead of the favicon. Immediately after uploading it it did show.
      • additionally settings towards the access also did not show in the form but seem to have been applied nonetheless
    • the new login screen simply shows "undefined" instead of the set title. Using https://github.com/bastienwirtz/homer/blob/main/public/assets/icons/favicon-32x32.png id properly shown as the favicon

    Edit: funny side effect of the new password auth. When you are in the admin panel and it loads a file as a preview it prompts you for the password in the preview pane.

    nebulonN 1 Reply Last reply
    0
  • nebulonN Offline
    nebulonN Offline
    nebulon Staff
    replied to fbartels on last edited by
    #16

    @fbartels ok look like I have to test this a bit more then. The preview pane issue is a good find!
    The favicons are currently simply taken as is and depending on the browser they may or may not be scaled down or not rendered at all it looks like. I probably have to either add some checks upfront or scale it prior to storing on disk.

    1 Reply Last reply
    0
  • nebulonN Offline
    nebulonN Offline
    nebulon Staff
    wrote on last edited by
    #17

    The preview and also other related issues like thumbnails is fixed with latest package version.
    I was not able to reproduce the missing username login field issue. Do you have any more information on this? Maybe in some cases we hit some caching issue or so?

    I also fixed an issue with the favicon in the settings dialog now. Still if too large images or unsupported formats are uploaded, they are just accepted and will thus result in missing favicons for now.

    fbartelsF 1 Reply Last reply
    1
  • fbartelsF Offline
    fbartelsF Offline
    fbartels App Dev
    replied to nebulon on last edited by
    #18

    No, I don't think its a caching thing as I am always trying the login form in an incognito session. This is with v5.13.3:

    d44e7a10-0b97-47e6-944c-a8d0717a5287-image.png

    Settings:
    40fdafaf-fed0-44c1-a5a5-5c33d0fe1ac4-image.png

    Under access control in Cloudron I have set Allow all users from this Cloudron.

    nebulonN 1 Reply Last reply
    0
  • nebulonN Offline
    nebulonN Offline
    nebulon Staff
    replied to fbartels on last edited by
    #19

    @fbartels oh! after looking at your instance itself I found the bug. You probably have the combination of access restriction and no public folder listing, in which case I missed to remove a token check. Will fix in a bit.

    fbartelsF 1 Reply Last reply
    0
  • fbartelsF Offline
    fbartelsF Offline
    fbartels App Dev
    replied to nebulon on last edited by
    #20

    @nebulon ah yes, that seems to be it. once I enabled public listing the login form did show the title and field for the username.

    Thanks

    nebulonN 1 Reply Last reply
    0

  • Login

  • Don't have an account? Register

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

  • Don't have an account? Register

  • Login or register to search.