Problem/Motivation

simple_ldap_user_user_load checks with LDAP every time a user entity is loaded. This is done to ensure consistency with the LDAP state. In fact it is our main down sync method. That means that user facing pages that display user information will be delayed by I/O operations against LDAP.

Proposed resolution

Skip this downsync in user load. Then downsync the data regularly using cron.

Remaining tasks

Make the regularity configurable.

User interface changes

None

API changes

None

Data model changes

None

Comments

e0ipso created an issue. See original summary.

e0ipso’s picture

Issue summary: View changes
StatusFileSize
new5.23 KB

This patch moves the downsync to a cron process completely. Now you can get your user synchronized by logging in or by cron.

e0ipso’s picture

Status: Active » Needs review

Status: Needs review » Needs work

The last submitted patch, 2: 3028122--avoid-downsync-user-facing--2.patch, failed testing. View results

karens’s picture

Status: Needs work » Needs review
StatusFileSize
new4.83 KB

I had a couple problems with this patch:

- The code at the beginning means this code is only executed once every 6 hours, no matter how often cron is run. It's already limited to running only when cron runs, which shouldn't be too often to hit a LDAP server. And it complicates attempts to fix a login if someone's account got blocked by confusing everyone about whether the LDAP credentials are broken or if the code just didn't run. I removed that restriction.
- The code pulls out a list of all users, then filters it using $authenticator->skipCheck($user), then checks to see if any accounts need to be unblocked. But that filter will remove all blocked users, so they will never get unblocked. I switched to use $authenticator->canAuthenticate($user->getUsername()) instead, which only filters out the anonymous user and user 1.

karens’s picture

StatusFileSize
new7.52 KB

After thinking more on this, there might be times when you want to restrict how often this is done, not because of any worry about the LDAP server but to reduce the hit on Drupal. For instance, if cron runs very frequently and LDAP users rarely change. So I added a configuration value for and worked it back in.

karens’s picture

StatusFileSize
new0 bytes
karens’s picture

StatusFileSize
new7.89 KB
karens’s picture

StatusFileSize
new8.33 KB

A further tweak, add system messages to tell you who has been activated or blocked or that the update was skipped.

  • KarenS committed fb6fd60 on 8.x-1.x
    Issue #3028122 by KarenS, e0ipso: Avoid LDAP searches that delay user-...
karens’s picture

Status: Needs review » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.