• Welcome to the Chevereto User Community!

    Here, users from all over the world come together to learn, share, and collaborate on everything related to Chevereto. It's a place to exchange ideas, ask questions, and help improve the software.

    Please keep in mind:

    • This community is user-driven. Always be polite and respectful to others.
    • Support development by purchasing a Chevereto license, which also gives you priority support.
    • Go further by joining the Community Subscription for even faster response times and to help sustain this space
  • Chevereto Support CLST

    Support response

    Support checklist

    • Got a Something went wrong message? Read this guide and provide the actual error. Do not skip this.
    • Confirm that the server meets the System Requirements
    • Check for any available Hotfix - your issue could be already reported/fixed
    • Read documentation - It will be required to Debug and understand Errors for a faster support response

Password protected albums bug

Status
Not open for further replies.

gareth.uk

Chevereto Member
Hi

I saw that you issued an update today that purported to fix the issue. I gave it a try as part of my evaluation over which software I should eventually settle on for my gallery.

I'm afraid the fix is incomplete.

Upon first loading the gallery, the passworded albums all look correct - the albums themselves are visible but no thumbnails are shown, and instead a padlock icon is shown. Clicking on any of the albums results in an "enter your password" screen.

Entering the password for a single album unlocks all other albums - is this expected? Those albums do all share a password but I kinda expected each one to need the user to input the password anyway. If this is expected then OK.

However, opening a brand new browser with a brand new session, I returned to the gallery to find that all of the passworded albums were now showing their thumbnails and were totally accessible to me - despite the fact that I had not entered any password on this new session. Given that there was no session data I thought perhaps you were doing it by IP, so I connected via 4G in order to get a new IP and nope, the galleries were still accessible. I even tried a totally different browser and they were still accessible. I can only assume therefore that they would also be accessible to other people - people who do not even know the password.

I left the gallery and came back several hours later to find that some of the private galleries were no longer accessible and clicking on them resulted in a "enter your password" screen. However, others WERE accessible and were still showing thumbnails. See the attached image for an example - as you can see, both of those albums are supposed to be private yet they both appear differently.

So... something still isn't right here I don't think.

So a little extra information.

After more time, the feature did start to behave as expected with private albums all showing a padlock until I entered the password, and I needed to enter the password on each one in order to view.

However, logging in as me (i.e. admin) is what breaks it. I log in as admin, view the albums, then log out again. Now all albums show the padlock. I enter the password for 1 of them and then they are ALL visible again as above.

So it seems logging out from an admin account doesn't fully work and I retain permissions to view the private albums after entering the album password once. I guess it starts to work properly after some time when my admin login session truly expires?

Correction, that last paragraph above should be:

So it seems logging out from an admin account doesn't fully work and I retain permissions to view all the private album thumbnails after entering a single album password. But I can only view the contents of the album that I entered the password for - clicking on the others results in the "enter password" screen even though I can see their thumbnails.

I'd guess there's something in the session that isn't right.
 
A big part of software development consist on try/update. It is totally normal to "don't behave as intended" on the first try.

I will review this and try to detect the reported behavior.

Thanks.
 
Well... I'm a software engineer myself (Swift, Objective-C, Haxe and Java) and... I wouldn't say such outcomes are "totally normal". 😛

But thanks for looking into it! 😉
 
Entering the password for a single album unlocks all other albums - is this expected?
I'm not getting this behavior. Unlooking one album doesn't show me on listings the cover images of albums that I haven't unlocked, even using the same password.

However, opening a brand new browser with a brand new session, I returned to the gallery to find that all of the passworded albums were now showing their thumbnails and were totally accessible to me - despite the fact that I had not entered any password on this new session.
Modern web browsers won't delete the cookie associated with a session. If you manually remove the PHPSESSID cookie you will notice that the session is gone. On logout, the system destroy the cookies and the session data.

I wouldn't say such outcomes are "totally normal"
Sure, in Software Engineering is not a normal thing. I'm a Software Developer, and in that context it is a normal thing (not saying that is something that you wish to happen, it just trends to happen).

--

The only issue I've found is that on user/albums the thing shows the album preview regardless if you enter a password or not. I've been unable to trigger the other stuff you are mentioning here.
 
Well, still not able to reproduce what you described here. The only thing I got was what I said earlier and that will get fixed in the next revision (that's the "confirmed" bug).
 
Status
Not open for further replies.
Back
Top