基于ldapjs的LDAP分页搜索：如何直接获取指定页码结果？

Great question! Let’s break this down clearly because LDAP’s pagination mechanism works a bit differently than the offset-based pagination you might be used to with databases. The short answer is: LDAP doesn’t have a native parameter to jump directly to a specific page—but there are two workarounds depending on your use case and LDAP server capabilities.

First, Understand LDAP’s Paging Limitation #

LDAP uses the Paged Results Control (RFC 2696) for pagination, which relies on a server-generated cookie (returned with each page of results) to fetch the next page. The server doesn’t track your pagination state or maintain page indexes—each cookie only works to retrieve the immediate next page. There’s no way to pass a "page number" parameter to skip straight to page 10 or 15 natively.

Workaround 1: Use offset to Skip Preceding Entries #

If your LDAP server supports the offset parameter (most modern servers like Active Directory do), you can calculate the total number of entries to skip and fetch your target page directly. This is the simplest approach for one-off requests.

How it works: #

• Your current sizeLimit: 100 defines your page size. To get page 10, you need to skip the first 9 pages (9 * 100 = 900 entries), then fetch the next 100.
• Add the offset property to your search options, set to the number of entries to skip.

Code Example: #

const opts = {
  filter: '(objectClass=user)',
  scope: 'sub',
  attributes: ["CN", "ou", "createTimestamp", "modifyTimestamp"],
  attrsOnly: true,
  sizeLimit: 100, // Page size (matches your original config)
  timeLimit: 5,
  offset: 900 // Skip first 900 entries to jump to page 10
};

client.search('DC=test,DC=com', opts, function(err, res) {
  if (err) {
    console.error('Search failed:', err);
    return;
  }

  const pageEntries = [];
  res.on('searchEntry', (entry) => {
    pageEntries.push(entry.object);
  });

  res.on('end', (result) => {
    console.log(`Loaded ${pageEntries.length} entries for page 10`);
    // Process your page data here
  });
});

Caveats: #

• Performance drops with large offsets: The LDAP server still has to iterate through all skipped entries before returning your target page. For very large offsets (e.g., page 1000), this can be slow.
• Some servers may restrict maximum offset values or disable this feature entirely.

Workaround 2: Cache Pagination Cookies for Repeated Access #

If you need to frequently access specific pages, you can pre-fetch and cache the cookies for each page during an initial full pagination pass. Once cached, you can use the cookie from the page immediately before your target to fetch it directly.

How it works: #

• When you first paginate through results, store each page’s next-page cookie in a cache (e.g., an object, Redis, etc.).
• To load page 10 later, use the cookie cached for page 10 (which was returned when you fetched page 9).

Code Example: #

// Cache to store cookies mapped to page numbers
const pageCookieCache = {};
const PAGE_SIZE = 100;

/**
 * Fetch a specific page, using cached cookies if available
 * @param {number} targetPage - Page number to load (starts at 1)
 * @param {Function} callback - Callback for results/errors
 */
function fetchLdapPage(targetPage, callback) {
  // First page doesn't need a cookie
  if (targetPage === 1) {
    const baseOpts = {
      filter: '(objectClass=user)',
      scope: 'sub',
      attributes: ["CN", "ou", "createTimestamp", "modifyTimestamp"],
      attrsOnly: true,
      sizeLimit: PAGE_SIZE,
      timeLimit: 5,
      paged: true
    };

    client.search('DC=test,DC=com', baseOpts, (err, res) => {
      if (err) return callback(err);
      const entries = [];
      res.on('searchEntry', (entry) => entries.push(entry.object));
      res.on('end', (result) => {
        // Cache the cookie for page 2 (next page after 1)
        if (result.control?.pagedResultsControl) {
          pageCookieCache[2] = result.control.pagedResultsControl.cookie;
        }
        callback(null, entries);
      });
    });
    return;
  }

  // Check if we have a cached cookie for the target page
  const targetCookie = pageCookieCache[targetPage];
  if (!targetCookie) {
    return callback(new Error(`No cookie cached for page ${targetPage}. Load preceding pages first.`));
  }

  // Use the cached cookie to fetch the target page
  const paginatedOpts = {
    filter: '(objectClass=user)',
    scope: 'sub',
    attributes: ["CN", "ou", "createTimestamp", "modifyTimestamp"],
    attrsOnly: true,
    sizeLimit: PAGE_SIZE,
    timeLimit: 5,
    paged: {
      pageSize: PAGE_SIZE,
      cookie: targetCookie
    }
  };

  client.search('DC=test,DC=com', paginatedOpts, (err, res) => {
    if (err) return callback(err);
    const entries = [];
    res.on('searchEntry', (entry) => entries.push(entry.object));
    res.on('end', (result) => {
      // Cache the cookie for the next page (if available)
      if (result.control?.pagedResultsControl) {
        pageCookieCache[targetPage + 1] = result.control.pagedResultsControl.cookie;
      }
      callback(null, entries);
    });
  });
}

// Usage example:
// First, pre-fetch pages 1-10 to cache cookies (run once)
// Then you can call fetchLdapPage(10, (err, entries) => { ... }) directly later

Caveats: #

• Cookies are temporary: LDAP servers invalidate cookies after a short period (varies by server), so your cache will need to be refreshed periodically.
• Data changes break alignment: If entries are added/removed between caching and fetching, the page number may no longer correspond to the same set of entries.

Final Notes #

• Use the offset method for one-off requests where performance isn’t critical.
• Use cookie caching if you need repeated access to specific pages and can tolerate periodic cache refreshes.
• There’s no way to skip directly to a page without either iterating through preceding entries (via offset) or pre-caching cookies—this is a limitation of LDAP’s pagination protocol, not ldapjs itself.

内容的提问来源于stack exchange，提问作者prashanthmadduri