Fix case-sensitive username check #71
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
We might want this to be a configuration option since it technically improves security. |
|
Good thought, I’ll do that tomorrow |
BaronGreenback
approved these changes
Jan 3, 2021
oddstr13
approved these changes
Feb 15, 2021
joshuaboniface
added a commit
to joshuaboniface/jellyfin-ldap-plugin
that referenced
this pull request
Feb 28, 2023
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 queries. 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 the new method, searches are case-insensitive, so the
option for case-insensitive username searches has been removed.
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.
Closes jellyfin#139 jellyfin#34
Obsoletes PR jellyfin#71
joshuaboniface
added a commit
to joshuaboniface/jellyfin-ldap-plugin
that referenced
this pull request
Feb 28, 2023
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 queries. 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 the new method, searches are case-insensitive, so the
option for case-insensitive username searches has been removed.
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.
Closes jellyfin#139 jellyfin#34
Obsoletes PR jellyfin#71
joshuaboniface
added a commit
to joshuaboniface/jellyfin-ldap-plugin
that referenced
this pull request
Feb 28, 2023
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 queries. 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 the new method, searches are case-insensitive, so the
option for case-insensitive username searches has been removed.
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
joshuaboniface
added a commit
to joshuaboniface/jellyfin-ldap-plugin
that referenced
this pull request
Feb 28, 2023
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 queries. 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 the new method, searches are case-insensitive, so the
option for case-insensitive username searches has been removed.
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
joshuaboniface
added a commit
to joshuaboniface/jellyfin-ldap-plugin
that referenced
this pull request
Feb 28, 2023
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 queries. 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 the new method, searches are case-insensitive, so the
option for case-insensitive username searches has been removed.
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
joshuaboniface
added a commit
to joshuaboniface/jellyfin-ldap-plugin
that referenced
this pull request
Feb 28, 2023
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 the new method, searches are case-insensitive, so the
option for case-insensitive username searches has been removed.
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
joshuaboniface
added a commit
to joshuaboniface/jellyfin-ldap-plugin
that referenced
this pull request
Feb 28, 2023
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
joshuaboniface
added a commit
to joshuaboniface/jellyfin-ldap-plugin
that referenced
this pull request
Feb 28, 2023
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #34
Thought this was already in, sorry!