LDAP Auth username is case sensitive #34
Comments
|
I think this is the issue... After a little Google maybe this will work? if (string.Equals(username, name, StringComparison.CurrentCultureIgnoreCase)) |
|
Just wanted to add that the fix proposed by @ossiozac works fine on my setup. |
joshuaboniface
added a commit
to joshuaboniface/jellyfin-ldap-plugin
that referenced
this issue
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 issue
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 issue
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 issue
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 issue
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 issue
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 issue
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 issue
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
Hello,
Thank you for the plugin, it's great not to have to have Emby Premium.
I am using this with MS Active Directory. When logging in, the username is case sensitive and I can't disable that, I believe that this should not be default behaviour as in LDAP it is generally all case insensitive.
My config is below:
Also the error when a user who doesn't exist or the password is wrong isn't very helpful for end users, maybe it could be a normal invalid username or password?
Many thanks
The text was updated successfully, but these errors were encountered: