Feat: Only allow authenticated users

[fbartels]

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.

[robi]

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

[fbartels]

@robi not that I know of

[nebulon]

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

[nebulon]

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

[fbartels]

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

[nebulon]

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.

[fbartels]

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

[nebulon]

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

[thetomester13]

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

[robi]

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

[girish]

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?

[nebulon]

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.

[nebulon]

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.

[fbartels]

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.

[nebulon]

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

[nebulon]

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.

[fbartels]

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:

Settings:

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

[nebulon]

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

[fbartels]

@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