@@ -273,26 +273,24 @@ For example, if your users have DN strings in the form
273
273
query_string
274
274
............
275
275
276
- **type **: ``string ``
277
-
278
- This (optional) key enables the user provider to search for a user and
279
- then use the DN found for the bind process. This is useful in environments
280
- with multiple LDAP user providers with a different ``base_dn ``. As value
281
- a valid search string for should be used, e.g. ``uid="{username}" ``. The
282
- placeholder value will be replaced by the actual username.
283
-
284
- When this key is used, ``dn_string `` has to be adjusted accordingly and
285
- should reflect a common denominator as base DN.
286
-
287
- Extending the previous example: If Your users have two different DN in the
288
- form of ``dc=companyA,dc=example,dc=com `` and ``dc=companyB,dc=example,dc=com ``,
289
- then ``dn_string `` should be ``dc=example,dc=com ``. In conjunction with
290
- ``uid="{username}" `` as ``query_string `` the authentication provider can
291
- authenticate user from both DN.
292
-
293
- Please bear in mind, that the usernames themselves have to be unique
294
- across both DN, as the authentication provider won't determine the
295
- correct user for the bind process if more than one are found.
276
+ **type **: ``string `` **default **: ``null ``
277
+
278
+ This (optional) key makes the user provider search for a user and then use the
279
+ found DN for the bind process. This is useful when using multiple LDAP user
280
+ providers with different ``base_dn ``. The value of this option must be a valid
281
+ search string (e.g. ``uid="{username}" ``). The placeholder value will be
282
+ replaced by the actual username.
283
+
284
+ When this option is used, ``dn_string `` has to be updated accordingly. Following
285
+ the previous example, if your users have the following two DN:
286
+ ``dc=companyA,dc=example,dc=com `` and ``dc=companyB,dc=example,dc=com ``, then
287
+ ``dn_string `` should be ``dc=example,dc=com ``. If the ``query_string `` option is
288
+ ``uid="{username}" ``, then the authentication provider can authenticate users
289
+ from both DN.
290
+
291
+ Bear in mind that usernames must be unique across both DN, as the authentication
292
+ provider won't be able to select the correct user for the bind process if more
293
47EB
+ than one is found.
296
294
297
295
Examples are provided below, for both ``form_login_ldap `` and
298
296
``http_basic_ldap ``.
0 commit comments