The current functionality of the password protect module for G2 is that the target album is password protected, but all descendants (children, grandchildren, great grandchildren, etc.) are not. These descendants have the core.view permissions removed so that when a user tries to directly access a descendant of a password protected album, without being authenticated first, they are redirected to the standard user login page and not the password module's password prompt page.
There were really two options when trying alleviate this issue.
1. Change the module's behavior when adding a password to an album to also add the same password to all descendant objects and remove the changing of the core.view permissions
2. Change the module's behavior to create a list of all descendant objects of a password protected album so when accessing the object directly, the module is smart enough to know that the target object is protected via a password protected ancestor. This option also requires the ignoring of the core.view permissions on the target object.
I went with the second option because it seemed to be the least costly and easiest to maintain. With this change (see patch file), now when an album that is a descendant of a password protected album gets accessed by an unauthorized user, they will be redirected to the password module's password page and not the core user login page.
The change may need to be tweaked a bit to better fit into all user cases, but initial testing on my system for my particular use case (password protected entire gallery by password protecting root album) provided favorable results. The issue I am concerned about is that in commenting out the check for the core.view permissions, I also commented out the check for $isHidden. I am not sure what affect this will have on standard operation since I did not have any hidden albums.
The attached diff was taken against gallery version 2.2.6 and is only applied to module.inc of the password protect module.
Eric Thompson
eric06@gmail.com
Patch to password module
Thanks for sharing this! I'm aware of this issue and it's quite annoying. This is a reasonable fix.
My concerns are purely from a developer / maintainer perspective. Explaining why I'm reluctant to merge this patch into the official version of G2. But that shouldn't stop anyone from using your patch manually.
--
"This option also requires the ignoring of the
core.view permissions on the target object."
I'm not a fan of this idea. I know that you're just following the pattern / precedent set by the password module, but ignoring core.view permissions (or any other permissions for that matter) is a bad idea since it makes it really hard to enforce security.
We need a single security mechanism, not multiple ones.
The basic problem with ignoring the core.view permission is that you'll implicitly disclose information about such items:
- you'll confirm that there is an item for this id
- you'll confirm that there's an item with that file name (since the URL rewrite module maps filenames to item ids) and that might be sensitive
- (there might be more)
I can't offer a really practicable solution at this point.
The only idea I had is this:
When you really want to send a link pointing to a child item of password protected album, then it should be a link to a link to the password login form with a return URL to the actual child item.
Say 77 is the item id of the protected album, and 99 is the id of the child item.
Then something like this could work:
http://example.com/gallery/main.php?g2_view=password.PasswordEntry&g2_itemId=77&g2_return=/gallery/main.php?g2_itemId=99
That's just a sketch, but that might work (you might need to change the params, the return param needs to be URL encoded, etc.).
And then, you could add an option in the password module's UI to provide such URLs in case you want to copy them and send the URL to a friend.
Or...
or just accept that one has to start a session always at the door, at the password protected album front page.