Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rework search flow to minimize LDAP search results #140

Merged
merged 3 commits into from
Mar 2, 2023

Conversation

joshuaboniface
Copy link
Member

The previous implementation would search for all users that potentially matched the (mandatory) configured search filter, then loop through the results to find a user matching one of the attributes.

This method worked fine for small instances, but became unwieldy for larger LDAP instances, and could even result in a Size Limit Exceeded error for extremely large databases.

This commit introduces a better method by integrating the user search component into the initial LDAP search by way of the search filter. This will ideally result in only a single LDAP search result for a given user rather than potentially dozens or hundreds, reducing both the runtime complexity of the plugin as well as the load on the LDAP server.

This new method has two potential ways of generating the limited search filter:

First, the existing search filter option may now accept a "{username}" variable within it, which will be interpolated at runtime based on what the user entered. This method allows for very complex queries to be crafted at will, providing better administrator flexibility and options.

Second, if no "{username}" variable is found within the search filter, the filter will be modified at runtime to include all of the search attributes combined with the username to generate a search query which will return any matches between the username and those attributes. For example, given attributes "uid" and "mail", a (base) search filter of "(objectclass=mailUser)", and the entered username "joshua", the following "real" search query would be produced:

(&(objectclass=mailUser)(|(uid=joshua)(mail=joshua)))

These two methods are, functionally, mutually exclusive: if the search filter contains the "{username}" variable, the search attributes will be ignored and may be blank/empty; on the other side, with valid search attributes, it is no longer necessary to specify a search filter at all, since there will still be a filter on the attributes and username. Thus, the plugin now accepts blank input for both fields in the configuration, though leaving both blank would not work properly.

In both cases with this change, searches are case-insensitive due to the case-insensitivity of LDAP search queries,, so the option for case-insensitive username searches has been removed as obsolete.

The new configuration is also backwards-compatible: if no changes are made to the search filter, the second method above will be used and this should continue to function exactly as expected.

Some debug messages have also been updated to provide a clearer picture of what the plugin is doing at various steps and aid in troubleshooting.

An explanation of the two methods above is included in the plugin configuration page, along with some rearranging of the options, to assist users in configuring the two fields the way they want.

Closes #139 #34
Obsoletes PR #71

The previous implementation would search for all users that potentially
matched the (mandatory) configured search filter, then loop through the
results to find a user matching one of the attributes.

This method worked fine for small instances, but became unwieldy for
larger LDAP instances, and could even result in a Size Limit Exceeded
error for extremely large databases.

This commit introduces a better method by integrating the user search
component into the initial LDAP search by way of the search filter. This
will ideally result in only a single LDAP search result for a given user
rather than potentially dozens or hundreds, reducing both the runtime
complexity of the plugin as well as the load on the LDAP server.

This new method has two potential ways of generating the limited
search filter:

First, the existing search filter option may now accept a
"{username}" variable within it, which will be interpolated at runtime
based on what the user entered. This method allows for very complex
queries to be crafted at will, providing better administrator
flexibility and options.

Second, if no "{username}" variable is found within the search filter,
the filter will be modified at runtime to include all of the search
attributes combined with the username to generate a search query which
will return any matches between the username and those attributes. For
example, given attributes "uid" and "mail", a (base) search filter of
"(objectclass=mailUser)", and the entered username "joshua", the
following "real" search query would be produced:

  (&(objectclass=mailUser)(|(uid=joshua)(mail=joshua)))

These two methods are, functionally, mutually exclusive: if the
search filter contains the "{username}" variable, the search attributes
will be ignored and may be blank/empty; on the other side, with valid
search attributes, it is no longer necessary to specify a search filter
at all, since there will still be a filter on the attributes and
username. Thus, the plugin now accepts blank input for both fields in
the configuration, though leaving both blank would not work properly.

In both cases with this change, searches are case-insensitive due to the
case-insensitivity of LDAP search queries,, so the option for
case-insensitive username searches has been removed as obsolete.

The new configuration is also backwards-compatible: if no changes are
made to the search filter, the second method above will be used and this
should continue to function exactly as expected.

Some debug messages have also been updated to provide a clearer picture
of what the plugin is doing at various steps and aid in troubleshooting.

An explanation of the two methods above is included in the plugin
configuration page, along with some rearranging of the options, to
assist users in configuring the two fields the way they want.

Closes jellyfin#139 jellyfin#34
Obsoletes PR jellyfin#71
@crobibero
Copy link
Member

Changes look fine, I would just rewrite this to use a stringbuilder and clean up some unneeded code/warnings

Index: LDAP-Auth/LDAPAuthenticationProviderPlugin.cs
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/LDAP-Auth/LDAPAuthenticationProviderPlugin.cs b/LDAP-Auth/LDAPAuthenticationProviderPlugin.cs
--- a/LDAP-Auth/LDAPAuthenticationProviderPlugin.cs	(revision 2e3875c55e4f91b80b34b5fb6435d6be5dfa305d)
+++ b/LDAP-Auth/LDAPAuthenticationProviderPlugin.cs	(date 1677680875839)
@@ -3,6 +3,7 @@
 using System.Linq;
 using System.Net.Security;
 using System.Security.Cryptography.X509Certificates;
+using System.Text;
 using System.Threading.Tasks;
 using Jellyfin.Data.Entities;
 using Jellyfin.Data.Enums;
@@ -323,7 +324,7 @@
                     LdapPlugin.Instance.Configuration.LdapBaseDn,
                     LdapConnection.ScopeSub,
                     filter,
-                    new string[] { UsernameAttr },
+                    new[] { UsernameAttr },
                     false);
 
                 // ToList to ensure enumeration is complete before the connection is closed
@@ -358,22 +359,36 @@
 
             string realSearchFilter;
 
-            if (SearchFilter.Contains("{username}"))
+            if (SearchFilter.Contains("{username}", StringComparison.OrdinalIgnoreCase))
             {
-                realSearchFilter = SearchFilter.Replace("{username}", username);
+                realSearchFilter = SearchFilter.Replace("{username}", username, StringComparison.OrdinalIgnoreCase);
             }
             else
             {
-                realSearchFilter = "(&" + SearchFilter + "(|";
+                var searchFilterBuilder = new StringBuilder()
+                    .Append("(&")
+                    .Append(SearchFilter)
+                    .Append("(|");
+
                 foreach (var attr in LdapUsernameAttributes)
                 {
-                    realSearchFilter += "(" + attr + "=" + username + ")";
+                    searchFilterBuilder
+                        .Append('(')
+                        .Append(attr)
+                        .Append('=')
+                        .Append(username)
+                        .Append(')');
                 }
 
-                realSearchFilter += "))";
+                searchFilterBuilder.Append("))");
+                realSearchFilter = searchFilterBuilder.ToString();
             }
 
-            _logger.LogDebug("LDAP Search: {BaseDn} {realSearchFilter} @ {LdapServer}", LdapPlugin.Instance.Configuration.LdapBaseDn, realSearchFilter, LdapPlugin.Instance.Configuration.LdapServer);
+            _logger.LogDebug(
+                "LDAP Search: {BaseDn} {RealSearchFilter} @ {LdapServer}",
+                LdapPlugin.Instance.Configuration.LdapBaseDn,
+                realSearchFilter,
+                LdapPlugin.Instance.Configuration.LdapServer);
 
             ILdapSearchResults ldapUsers;
             try
@@ -382,7 +397,7 @@
                     LdapPlugin.Instance.Configuration.LdapBaseDn,
                     LdapConnection.ScopeSub,
                     realSearchFilter,
-                    new string[] { UsernameAttr },
+                    new[] { UsernameAttr },
                     false);
             }
             catch (LdapException e)

@joshuaboniface joshuaboniface requested a review from a team March 1, 2023 20:36
@crobibero crobibero added bug This PR or Issue describes or fixes something that isn't working feature This PR or Issue requests or introduces a new feature labels Mar 2, 2023
@joshuaboniface joshuaboniface merged commit ddffe7f into jellyfin:master Mar 2, 2023
@joshuaboniface joshuaboniface deleted the improved-search branch March 2, 2023 18:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug This PR or Issue describes or fixes something that isn't working feature This PR or Issue requests or introduces a new feature
Projects
None yet
Development

Successfully merging this pull request may close these issues.

LdapException: Size Limit Exceeded (4)
2 participants