Feat: Only allow authenticated users

[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

[nebulon]

@fbartels Ok this should be fixed with the latest package release now. Thanks for all the testing and reporting!

[fbartels]

@nebulon said in Feat: Only allow authenticated users:

Thanks for all the testing and reporting!

I asked for the feature, it was the least I could do

[robi]

I am trying this out and have a few issues.

Enabling the public folder listing and setting access to user restricted, should not list the content until a user is logged in.

If I open the site in a new tab, it lists the files and shows a login button. Not expected.

If I open an incognito tab, it opens to a login page. As expected.

So the new tab should either give me a login page, or tell me I am logged in, if a browser session is being used to display the file listing.

[nebulon]

@robi can you explain the "Not expected" case a bit further. Which and where do you see a login screen? (The login button in the public folder listing on the top right will always be there, if that is what you mean)

[robi]

@nebulon expectation is to not get a listing and a login prompt.

since I did, that means the session is being reused and I am logged in, yet the button shows as I am not logged in.

So maybe the fix here is to detect login state and adjust the button accordingly; perhaps a logout instead.

[nebulon]

Right, since you have the access token in this case in a new tab simply in the local storage, the session is refreshed and you see the files. I will fixup the login state/login button to show somethign like "Admin Dashboard" or so.