Allowing Access For Unauthenticated Users?

Here is a very simple patch (1 line removal and 1 line edit in page_access.module) to allow "Anonymous user" role check box in Roles section, and "Anonymous" user option in users autocomplete box search. This doesn't break the default functionality of the module. Checking the "Enable page access control" box on any node will still default to block anonymous users. However, this gives the admins the rightful power to allow anonymous users to view+edit by role, or view and/or edit by specified "Anonymous" user.

I still think the logic should be split out for the roles section to allow fine grained control over whether a role can or cannot edit, but I haven't looked into that yet.

EDIT: upon further testing, it appears that selecting "Anonymous" from the user dropdown doesn't successfully allow anonymous users to view the node, using the patch above. The "Anonymous user" role checkbox does work. I am not sure what is preventing the user type-in from working, but will look into it.

EDIT 2: Ignore this patch, review the one in comment below.

I've created a new patch that's a little more robust. It does not allow "anonymous" typed into the user search box, but does allow all the functionality we need via the anonymous role. This patch breaks out the edit permissions by role, so you can enable roles as view only, with the option to also provide edit by role via an additional check box. This patch works in my environment, but I'm wondering if dual role check boxes is the wrong way to go about it. I will look into creating a new patch that uses drop downs instead with options "blocked", "view", "view & edit".

You'd probably want to test this patch on a dev site, or maybe a fresh/new site. If building a new site is too much work, you could drop the records in your page_access table to prevent wonkiness. Maybe there won't be any wonkiness transitioning to the patch, btu I don't have a live environment with PA set up on pages to patch and find out for myself.

EDIT: I think the UI in the patch in the comment below is better, cleaner, and more intuitive. I'd prefer we use that and ignore this one, but feel free to test and provide feedback.

alright, I think I've got what we want. This new patch is the same functionality as the one above, but with a more intuitive (IMO) UI, where dropdowns are used instead of checkboxes for the role settings. Please review and provide feedback.

Ive gotten an email response from @manojapare that they will be considering the patches. Hopefully we will see an update soon.

If the project developers indicate that they have any interest whatsoever in rolling in the feature, I'd be happy to. For the time being, despite this project being labeled as "actively supported", it seems to be dead.

Great, thanks @hamrant. I will follow that issue and see if anything comes of it. In researching this module more (in comparison to Content Access), I also came across this interesting critique (also related to maintainer-ship): https://www.drupal.org/node/2032001#comment-11969740

Thanks @rakesh.gectcr and @hamrant. It sounds like there may be some security issues that should be addressed before this specific issue. I don't have access to it, but this link was shared elsewhere: https://security.drupal.org/node/161758

@hamrant, I don't think I should re-roll allow_anonymous_user_and_role.patch and support_anonymous_role_and_edit_by_role_checkboxes.patch because I think they are the less-than-ideal options. However, I have gone ahead and re-rolled the patch I think we should move forward with (support_anonymous_role_and_edit_by_role_dropdown.patch) to fix some of the Drupal Coding Standard issues I found.

See: support_anonymous_role_and_edit_by_role_dropdown_REROLL_1.patch

If you see any other DCS issues with it, please be explicit. Hopefully you get added as a maintainer and can take it from there if you've tested and like the functionality.

.

Why is an unaffiliated non-maintainer with no post history closing this issue?

I am no longer using or planning to use this module for various reasons. Regardless, @Prince John, you are simply misunderstanding/ignoring an extremely simple and common use case: "Everyone should be able to access this page but only Role X should be able to edit it". This use case requires "View" permission for Anonymous user and "View and Edit" permissions for "Role X".

Unfortunately, it appears that the module maintainers are investing very little effort in this module's issue queue. The "actively maintained" label is a misnomer.

thanks for reviewing @podarok!