When optimizing grants, Content Access assumes that the Authenticated User role is a superset of all other user-defined roles. However, when using LoginToboggan there may be an 'unvalidated' role which is not a sub-role of Authenticated User.

This can cause issues such as the unvalidated user being unable to view their own content, if grants are given to Authenticated and 'unvalidated' users. Content Access optimizes the grants to only the Authenticated role, which then excludes the unvalidated user when they grant is checked.

The following patch modifies the grant optimization if LoginToboggan is installed, and the 'unvalidated' user role is enabled.
In order to grant view access to all roles, the unvalidated role must be checked in addition to Anonymous and Authenticated. I think that it would be rare in practice to have rules which deny the unvalidated role but grant access to the two others, so this shouldn't make existing grants less optimal. (Typical cases should be Anon-Unval / Auth-Unval / Anon-Auth-Unval)
If the Authenticated role is granted an operation, the 'unvalidated' role is given special treatment similar to the anonymous role, so that it is not removed from the given grants.

CommentFileSizeAuthor
#12 content_access-915170-12-D6.patch1.38 KBgapple
#12 content_access-915170-12-D7.patch1.33 KBgapple
#9 content_access-915170-logintoboggan-settings.png24.48 KBgapple
#9 content_access-915170-auth-unauth-access.png77.54 KBgapple
#9 content_access-915170-auth-unauth-view.png72.81 KBgapple
#9 content_access-915170-anon-auth-access.png77.54 KBgapple
#9 content_access-915170-anon-auth-view.png73.07 KBgapple
#5 content_access-915170-5.patch1.29 KBgapple
#4 content_access-915170-4.patch18.73 KBgapple
#4 logintoboggan-915170-4.patch689 bytesgapple
content_access-logintoboggan-conflict.patch1.56 KBgapple
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

butler360’s picture

butler360 CreditAttribution: butler360 commented

I just ran into this issue and here I find a fresh patch waiting to be tested!

Patch applied cleanly (although it did say "Stripping trailing CRs from patch"). After rebuilding permissions it fixed the issue! Thanks!

gapple’s picture

gapple
he/they
Primary language English
CreditAttribution: gapple commented

Thank you for testing @butler360!

I probably created the patch before properly setting up my IDE to always use UNIX line endings (Eclipse doesn't make it easy).

good_man’s picture

good_man CreditAttribution: good_man commented
Status: Needs review » Needs work

We need a general solution for that not just for loggintoboggan.

gapple’s picture

gapple
he/they
Primary language English
CreditAttribution: gapple commented
Status: Needs work » Needs review
FileSize
logintoboggan-915170-4.patch689 bytes
content_access-915170-4.patch18.73 KB

My only thought for a general solution is a hook to allow modules to return roles that should receive special treatment. I'm not aware of any other modules that would make use of this at this time.

Haven't tested it out yet, but here's what I think could work. Suggestions for a better hook name would be appreciated.

gapple’s picture

gapple
he/they
Primary language English
CreditAttribution: gapple commented
FileSize
content_access-915170-5.patch1.29 KB

I should check out my patch files before upload...

The patch for content_access seemed to grab some changes from an older commit as well, and I noticed that I didn't initialize a variable before use, so here's the corrected patch.

good_man’s picture

good_man CreditAttribution: good_man commented

@gapple: thanks for your work, but I've tried logintoboggan and it didn't create such role, and I tried to create content and assign view to auth. and it worked for unvalidated users. Any steps to reproduce?

gapple’s picture

gapple
he/they
Primary language English
CreditAttribution: gapple commented

The unvalidated role must be created manually and then assigned on the logintoboggan admin page (Non-authenticated role field in the Registration fieldset).

Then create content with permissions for the Authenticated and the non-authenticated role you created.
After saving, the node grants table will only contain an entry for the Authenticated role.

If a user that has registered but not confirmed their email address tries to access the content, they will be denied (as I understand, LoginToboggan removes the Authenticated User role from these users)

good_man’s picture

good_man CreditAttribution: good_man commented

I tried the steps you mentioned and it's working great, make sure there is not other module that causing this conflict.

gapple’s picture

gapple
he/they
Primary language English
CreditAttribution: gapple commented
FileSize
content_access-915170-anon-auth-view.png73.07 KB
content_access-915170-anon-auth-access.png77.54 KB
content_access-915170-auth-unauth-view.png72.81 KB
content_access-915170-auth-unauth-access.png77.54 KB
content_access-915170-logintoboggan-settings.png24.48 KB

Just ran through things again on a local test site.
Base Drupal install, with only Content Access, LoginToboggan, Admin Menu, and Devel installed and enabled.

1. Create a new role 'un-auth', and grant 'access content' permission
2. Configure LoginToboggan: Enable 'Set Password' and set Non-authenticated role to 'un-auth'
3. Create user accounts: Authenticated user can be created by admin, unauthenticated user must be created by using the user registration form
4. Set 'Story' content type permissions
5. Create a Story node
6. View node

Here are some screen shots of the settings and consequent node views with Devel showing the node access records:
Authenticated and Un-auth This setting is optimized to just 'authenticated', erroneously denying access to un-auth users.
Anonymous and Authenticated This setting is optimized to 'all roles', even though un-auth should not be given access (granted, this is not a likely use-case).

good_man’s picture

good_man CreditAttribution: good_man commented

OK now I got what you mean, you didn't make it clear that *you* want this behaviour, and I thought what you want is what's going on now and it's bug :)

So did you open an issue in logintoboggan issue queue with your patch? (of course our patch needs to go in first so they can use it).

gapple’s picture

gapple
he/they
Primary language English
CreditAttribution: gapple commented

I've just opened an issue in the LoginToboggan queue: #1213466: Content Access compatibility contrib module

gapple’s picture

gapple
he/they
Primary language English
CreditAttribution: gapple commented
FileSize
content_access-915170-12-D7.patch1.33 KB
content_access-915170-12-D6.patch1.38 KB

The issue in LoginToboggan has been fixed with the commit of a compatibility module in both 6.x and 7.x branches.

I've attached patches for 6.x and 7.x, though there are no differences between the two.
They improve upon my previous patch by replacing the foreach loop with array_intersect.

RedRock2512’s picture

RedRock2512 CreditAttribution: RedRock2512 commented

Is this patch in the latest DEV version?

gapple’s picture

gapple
he/they
Primary language English
CreditAttribution: gapple commented

These patches aren't in DEV yet; when they are this issue will be marked as closed.

Testing and marking RTBC would be helpful in getting these patches added.

mrP’s picture

mrP CreditAttribution: mrP commented
Version: 6.x-1.x-dev » 7.x-1.x-dev
Issue summary: View changes
Status: Needs review » Needs work

If there is any chance of this getting fixed, it will go into D7 first and then potentially ported to D6.

When I tested the patch, I used it on an existing site with existing permissions (tested a new registration of course as well as rebuild permissions), and still had the same issue.

gapple’s picture

gapple
he/they
Primary language English
CreditAttribution: gapple commented

@mrP did you enable the integration module that is part of logintoboggan as well? The latest patch relies on it's hook implementation in order to work correctly.

mrP’s picture

mrP CreditAttribution: mrP commented

I did indeed. LoginToboggan Content Access Integration was enabled during my testing.

fago’s picture

fago
Primary language German
Location Vienna
CreditAttribution: fago commented
Status: Needs work » Closed (works as designed)

However, when using LoginToboggan there may be an 'unvalidated' role which is not a sub-role of Authenticated User.

Well, then LoginToboggan hacks the role system in a way it's not built for. I do not think that content access should account for anything that does not go with Drupal's role model.

Still, one could do a small module that alters the grants accordingly.

myDrupal2014_846824658246’s picture

myDrupal2014_846824658246 CreditAttribution: myDrupal2014_846824658246 commented

I'm running in this issue now.
Using :
- Content Access 7.x-1.2-beta2
- LogintoBoggan 7.x-1.4

Can I apply the patch mention by :
https://www.drupal.org/node/915170#comment-5005874

I'm just new in patching ....