LDAP Authorization 7.x-2.x and Organic Groups 7.x-1.5: Group Granting and Revoking

I'm having the same issue, with very similar looking tests/logs, using the latest dev.

Aside from on logon, I don't see any code to remove og groups. An option to remove via cron batches should be added at http://drupalcode.org/project/ldap.git/blob/refs/heads/7.x-2.x:/ldap_aut... or integrated in the ldap_user modules batch process.

When you say you are testing and the groups are not removed, are you testing by logging on?

I will be working on this later in the week, with the following steps:

1. get the simpletests working for og 1.5 and ldap 7.x-2.0-dev
2. test and fix that revokes and grants are functional on logon
3. integrate functionality for authorization revokes and grants driven by cron. this will apply to all ldap authorization modules.

john your comment makes me think you are assuming his issue is really specific when it isn't. The point is that the OG assignment / revocation is completely broken when it shouldn't be -- the testing part of the interface appears to indicate the correct assignment of OG membership (for both OG 7-1.5 in his case and 7-2 in mine) but it doesn't actually work on logon in practice.

I'm going through this now. Kazanir is correct, there are a number of issues with the og 7.x-1.5. Its broken in a non subtle way, so hopefuly will be easy fixes.

Here's hoping that the same stuff applies to the 7-2 implementation. What I'm seeing looks extremely similar to Scott's results except for the initial OG mapping text (mine is mappingresult|node:nodeid:roleid naturally) -- functioning tests and mappings being mapped correctly in the logs, but no actual group memberships being created.

OG assignment appears broken for me as well, on 7.x-2.x-dev (2013-Feb-14). I made a group, configured the LDAP server, configured the authorization, added a group mapping, and the test seems to run fine. It correctly finds the 3 groups my test user is in, finds the match for the one mapping I made, and the "Results after any filtering and mappings applied" section says "node:2:2", which if I understand the syntax, means that my test user should be be assigned to group 2 with role 2. However, I log in with that user in another browser, and he never shows up in the member list.

So, to be clear, I can't get LDAP users into a group to begin with.

Aside: I'm using CAS auth, not LDAP auth, but it's an otherwise vanilla install.

In the initial comment, the configuration is off. If only using first attribute in mapping/filter, they should look like:

Intranet HIS Content Manager|gid=170,rid=5

not

CN=Intranet HIS Content Manager,...|gid=170,rid=5

The og_group mapping filter I'm using (based on the Harry Potter examples from the config page) looks like this:

InformationTechnologyGroup|node:2:2

It shows as enabled on the /admin/config/people/ldap/authorization/ page. The results of a test on a known-good LDAP user are pasted below. The test results make me believe that the mapping works and is enabled, but my test users are never added to the InformationTechnologyGroup og group (/group/node/2/admin/people). Is "node:2:2" a valid end result for the group mapping?

Note: my test user belongs to three LDAP groups (InformationTechnologyGroup, AdmGroup, Faculty), but only one is mapped in the og_group authorization configuration.

Another note: this problem still affects me on ldap 2-0-dev (2013-Feb-18), and the recent OG 2.0 final release.

PREFILTERED AND FINAL MAPPINGS

Derive from DN (without filter):

disabled

Groups DNs (without filter)

• cn=InformationTechnologyGroup,ou=group,dc=university,dc=edu
• cn=AdmGroup,ou=group,dc=university,dc=edu
• cn=Faculty,ou=group,dc=university,dc=edu

AFTER "CONVERT FULL DN TO VALUE OF FIRST ATTRIBUTE BEFORE MAPPING"

Convert full dn to value of first attribute before mapping

• InformationTechnologyGroup
• AdmGroup
• Faculty

AFTER MAPPINGS AND FILTERS APPLIED

Use Mappings as Filter = 1

Configured Mappings

InformationTechnologyGroup|node:2:2

Results after any filtering and mappings applied

• node:2:2

Your mappings are correct and looks like all is working well except the actual saving of the group membership. This is likely a bug in the saving part. The og_role_grant() calls in LdapAuthorizationConsumerOG.class.php are where the group memberships should be saved.

Are you using ldap_authentication?

Its remotely possible that its an artifact of a previous bug. By this I mean:

- if you have regrant ldap provisioned unchecked and
- there is a record in $user->data['ldap_authorization'] indicating the group was already granted
- but the group membership was never actually granted

It will not grant the group membership. To eliminate this as a possibility, delete the test user and test again.

The second part is unlikely, as the watchdog logs indicate the step where OG authorization strips "previously granted" group memberships. Since I have the "re-grant" checkbox checked, my authorization result makes it past this step, but is still not saved. It seems clear that something about saving the OG membership is going wrong.

There seems to be a problem saving mapings in user object. When og_groups are saved user_roles are deleted and on sync when ldap maps first roles already mapped og_groups are deleted, this caused the process to always apply current mapping and avoid revoke of groups. This small change seems to fix the problem.

They're never assigned for me, either. I'm not using any other parts of LDAP; just the server config and the og_groups.

There are a number of issues including simpletest coverage. I'm adding test coverage of the 1.5 og then will start working through the mapping and record keeping part. Part of that is #16 patch. Part of its already been resolved by some ldap_user and ldap_authentication patches. Lets keep this thread open until all the mappings to og are functional. I realize this will be a rather broad issue, but some of these are closely related.

Patch #16 should have no effect. I'm committing it to avoid confusion since it will not hurt the user->data array either. Its pushed to 7.x-2.x-dev.

The function hasAuthorization() for og 1.x was broken. I committed a fix:
http://drupalcode.org/project/ldap.git/commitdiff/44650af7e9a6cd473f915c...

This will help with some og 1.x issues.

Attached is a patch that does the following:

- fix loading og group in revokeSingleAuthorization. This would have resulted in og 1.5 group roles never being removed since the group would never have been found.
- changes og_invalidate_cache() to only invalidate cache of single group being worked with. This will be a performance improvement.

I will commit this after the test coverage for og 1.5 is better; but please look at over and try it out.

@#23. Thanks. This is helpful. This will clarify itself as I work through the functional tests for og 1.5. I will be sure to add tests to compare against a membership assignment via the UI rather than the api/functions.

I committed a patch for a number of issues for og 1.5. The gist of the fixes are:

• testing for membership must test for both membership and roles, not just roles.
• revoking the last role, must also remove the membership
• revoking the default authenticated membership must also revoke any other roles

The commit is: http://drupalcode.org/project/ldap.git/commitdiff/285fa26e0a5f5f3043761e... and is specific to og 7.x-1.5 (not og 7.x-2.x). I still need to finish the simpletests for og 1.5 to make sure all the edge cases are functional and the functional tests for logins are covered.

See also [#http://drupal.org/node/1115704#comment-7162346]

I can make a fix for previous users. If you can send me a couple of their user records I'll figure out what is going on. I suspect it has to do with the authmap.authname being set correctly. The fix/patch will be both to catch the error and fix past user data when appropriate.

Can you send me a few user records that do not function. That way I can replicate it and make sure its fixed. Here is a query:

select u.uid, u.mail,u.init, cast(data AS char(1000)) as data, a.authname, a.module from users u left outer join authmap a on a.uid = u.uid

I gave up on the og 7.x-1.x code within ldap authorization and rewrote it. The recurring issue was overriding individual grant and revoke functions in the LdapAuthorizationConsumerAbstract class. By trying to do individual grants/revokes a number of issue came up and I eventually got tired of chasing in circles.

The new code overrides the whole grants and revokes (grantsAndRevokes()) so so efficiencies are also gained. This is committed, but not thoroughly tested yet.

I'm making this thread specific to LDAP Authorization 7.x-2.x and Organic Groups 7.x-1.5.

I was experiencing precisely the same issues with OG 7.x-2.x -- does the code you have touched so far ONLY deal with OG 1.5?

I can test the latest dev with OG 2.x later today I suppose.

Generally it doesn't touch og 2. Many of the changes are applicable to og 2, but I'm unclear if og2 works or not. I had some funding to get the og 1.5 working and found several issues. og 2 is a little easier to work with so am not clear if the same issues are there. Also ldap authorization for og 2 has much better test coverage so is easier to code.

Please tests and start a thread "LDAP Authorization 7.x-2.x and Organic Groups 7.x-2: Group Granting and Revoking" if anything comes up.

Thanks. I'll test and debug this. I just finished the test coverage for og 1.5 and committed it. There was also a small array bug. This is all committed (see http://drupalcode.org/project/ldap.git/commit/eb390c1)

I'll test/fix the revoke/unrevoke pattern and add simpletests for it next.

I can't replicate #33. I'm trying to recreate it in the test coverage also, but haven't finished the test coverage.

I managed to replicate #33! Hopefully will be an easy fix. I cannot replicate it with any roles other than OG Admin role. With default roles or custom global roles, the issue doesn't seem to happen; I could be wrong about this as I have a small test set of groups.

The second mapping below is granted and revoked on alternating logons. The other 2 behave correctly.

students|group-name=Students,role-name=member
staff|group-name=Staff,role-name=administrator member
webmaster|gid=3,rid=4

Are you having issues with any other types of roles being revoked?

Edit: I'll make a new issue for this.

The latest patch http://drupalcode.org/project/ldap.git/commitdiff/1e346a8747a0440726d1ab... is committed to 7,x-2.x-dev and deals with the alternate revoking and granting of og 1.5 roles. Please test.

The basic approach was to create an authorizationDiff($existing, $desired) method which dealt with og 1.5 cases differently.

I'm having this exact issue. I tried patch #38, but this test feature for granting and revoking OG roles is still not working for me at admin/config/people/ldap/authorization/test/og_group. For me, it says that it's successful, but doesn't actually grant/revoke the OG roles. The regular grant/revoke feature for LDAP to Drupal roles is working fine: http://test/drupal/admin/config/people/ldap/authorization/test/drupal_role

I'm using 7.x-2.0-beta5. Do you have any suggestions on what else I can do to get this working? I don't want to use a dev version with my live site for obvious reasons.

It seems, I am having the same problem as jayhawkfan75. I'm using 7.x-2.0-beta5 as well and have already tried the current 7.x-1.0-beta12 as well as 7.x-2.x-dev. The problem persists.

Roles are assigned just fined while any groups are revoked as soon as a user logs on. Deactivating LDAP_Authorization for OG or LDAP Authorization for roles separately doesn't help. Deactivating both at least stops the complete revocation of user groups.

Something strange that I noticed: Manually revoking/resetting ROLES from a user seems to trigger something as on the next log on the user is granted the correct roles as well as the correct groups. However on the next log on all groups are revoked again.

I can at least tell that the problem comes from the LDAP-module. Commenting the else part from the following code lines (in ldap.authorization.module) puts an end to the revoking problem, but obviously also stops the granting of roles or groups altogether.

function ldap_authorizations_user_authorizations(&$user, $op = 'query', $consumer_type = NULL, $context = NULL) {
  ldap_servers_module_load_include('inc', 'ldap_authorization', 'ldap_authorization');
  if ($consumer_type != NULL) {
    list($new_authorizations, $notifications) = _ldap_authorizations_user_authorizations($user, $op, $consumer_type, $context);
  }
  else {
    $consumers = ldap_authorization_get_consumers();
    $new_authorizations = array();
    $notifications = array();

    foreach ($consumers as $consumer_type => $consumer) {
      list($new_authorizations_i, $notifications_i) = _ldap_authorizations_user_authorizations($user, $op, $consumer_type, $context);
      $new_authorizations = $new_authorizations + $new_authorizations_i;
      $notifications = $notifications + $notifications_i;
    }

  }
  return array($new_authorizations, $notifications);
}

I have no idea what even happens at this part as the function just returns to the login hook as some point with the revoking and granting happening somewhere inbetween.

Any help would be appreciated.

I don't want to step on any toes, but I feel that I have to mark this issue as active since it's still occurring for me and senorincognito with the newest release versions. I did a thorough check of my LDAP OG mappings before responding, and the grant/revoke feature is still not working at all for me. I'm currently using LDAP 7.x-2.0-beta5 (including LDAP OG) and Organic Groups 7.x-2.3.

The test reports say that it was successfully granted, but that group is still not listed under by Group Membership list when I try to use this testing feature. Luckily, my OG groups get assigned properly when I log in normally. So at least that is working.

My only workaround to get this site going was to go through every user on the site and assign them to their groups. This grant/revoke feature would have saved me a lot of time, as it was a very time-consuming process.

If any additional reports will help the maintainers solve this issue, please let me know which ones you need. Hopefully it will get fixed soon.

This issue is specific to OG 7.x-1.x branch and LDAP Authorization 7.x-2.x. Please start another issue for anything related to OG 7.x-2.x; they are quite different.

It seems the problem is related to this issue: https://drupal.org/node/1588068

I've found three additional occurences of user_save() in the Authorization module. Applying the proposed fix to the user_save()-function in ldap_authorization.inc fixed the issue to a certain degree. Applying the fix to the other two occurences didn't seem to do anything at all.

In conclusion: At least group memberships are not randomly deleted while still being applied normally on user login. The only issue remaining is when a user already has any roles assigned to him no group memberships are assigned whatsoever.

One more correction.

As noted by johnbarclay in #46 above, this issue was fixed for OG 7.x-1.x.

The following new issues have picked up the conversation with new reports of similar problems.

• #2023493: ldap authorization og: Alternating between assigning and revoking groups
• #2064319: LDAP Authorization OG: OG Groups not assigned to users with Administer Organic groups permission
• #2144637: LDAP Authorization 7.x-2.0-beta6 and OG 7.x-2.4 - roles only assigned on initial login

Setting this issue back to Closed (fixed).