Node Gallery Access Password Protection isnt' working

I don't think you're doing this the right way. When node_gallery_access is enabled, you should always have more than one row in node_access. You just worked around the bug temporarily - once you rebuild permissions, your node_access table will be repopluated, and you'll see the bug.

So, in between busy work, and sick children, I've had a little bit of time to look into this. There's a little bit of a catch-22 here.

In order to make password protected galleries not show up in node lists (like the home page, or views), password protected galleries and their images are added to the node_access table with restrictions. This removes them from node listings (unless you're the owner, admin, or have the "view password protected galleries without a password" permission). This is the desired effect.

If you navigate directly to a gallery that is password protected, and you don't have any of the permissions listed above, then you are shown the password form. This is also the desired effect.

If you enter the correct password, you are allowed to bypass the form, but then the node_access rules kick in, and you get message about access being denied. Even though you've entered the correct password, node_access is still stopping you from getting to the page. This, obviously, is *not* the desired effect.

The easy fix here is to just allow everyone access to the nodes via node_access, and use the form based protection to limit access, but this has the drawback of the password protected galleries showing up in views and node lists.

node_access doesn't lend itself well to allowing temporary access, so what I really need here is a way to circumvent/override node_access. Does anyone know of a way to do this?

There's a couple other modules I have in mind that do similar things, I'll look into those as well.

So, there isn't an easy way to easily supersede Drupal's node access rights model on a per session basis. When assigning grants to a user, we don't have a node, so we'd likely have to create a separate realm for each and every password protected gallery. While that may work, I can't imagine it would scale very well.

Other modules that I've looked at basically give an anonymous user temporary access to a node by letting them assume the user account of another user. This approach is based upon users, while our approach needs to be based upon nodes, not to mention the security nightmare this could potentially cause.

We could use the hook_access method, but that would require registering node_gallery's node types with hook_info. Given that the node types are dynamic, this could be quite tricky. Also, I believe this hook is going away in D7.

So, to think outside the box a bit, here's how we can tackle the issue. I'll set up the module so that both Public and Password node types allow all access via Drupal's node access rights (node_access table). Only Private nodes will have restricted access via node_access.

This will allow password protected nodes to show up with the "protected" icon in node listings, but prompt the user for the password when they attempt to view the node.

To satisfy those who want password protected nodes to not show up in node lists (myself included), we can tackle this with views. I will add a filter to our views integration that will allow us to filter nodes based upon the node_gallery_access type of Public, Private, and Password.

If I can get some time this weekend, I should be able to get this module working properly.

The attached patch should resolve this issue, as well as #650022: default cover for galleries password protected not show. Note that as mentioned in #6 above, all password protected galleries will be available for listing by anyone. If the user doesn't have the proper permissions or a password set, then they will see the "protected" version of the node. When I dive into the views implementation, I'll provide some filters that will allow admins to create views that do not display password protected galleries in lists.

Forgot to add that you need to rebuild your access permissions after applying the patch.

I apologize, but I'm having trouble understanding you. I don't know how you can have a "clean install" but have a "edited .module file already"...

I just now got CVS commit access to the project, and have committed my changes to CVS. Try checking out the CVS dev branch from today (I'm pretty sure you know how, but if not, it's documented here: http://drupal.org/node/330271/cvs-instructions/DRUPAL-6--2), then rebuild permissions at /admin/content/node-settings/rebuild. If you have the devel module installed, clear caches /devel/cache/clear for good measure. To make really sure somethings not stuck in your PHP session, bump Apache. Then test, and let me know what you get.

I was able to reproduce the bug before, but can't any longer after applying my fix.

@gothica, you're posting a support request to a fixed bug report.

Please start a new issue as a support request - I don't think this is a bug yet, because it works just fine for two people.

It looks like your site looks pretty customized - I wonder if the problem is your theme. I've been doing my tests with the garland theme. Try to reproduce your issue with the garland theme, and post the results in the new support request thread.

@gothica, if you want help resolving your issue, I suggest you stop re-opening the wrong issues. The maintainers have enough to do without having to re-close fixed issues.

It's fixed in CVS http://drupal.org/node/330271/cvs-instructions/DRUPAL-6--2