mirror of
https://github.com/lldap/lldap.git
synced 2026-04-25 16:25:55 +03:00
[GH-ISSUE #738] [FEATURE REQUEST] ldap query filter supports regualr expression #267
Labels
No labels
backend
blocked
bug
cleanup
dependencies
docker
documentation
duplicate
enhancement
enhancement
frontend
github_actions
good first issue
help wanted
help wanted
integration
invalid
ldap
pull-request
question
rust
rust
tests
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/lldap-lldap#267
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ctaoist on GitHub (Nov 18, 2023).
Original GitHub issue: https://github.com/lldap/lldap/issues/738
Motivation
Stalw art: An Secure & Modern All-in-One Mail Server (IMAP, JMAP, SMTP) written in rust.
Describe the solution you'd like
Stalwart request ldap queries with filters
domains = "(&(objectClass=posixAccount)(|(mail=*@?)(mailAlias=*@?)))", and the?character in the queries denotes a domains parameter that will be filled in at runtime.But now the wildcard
*would be discard in filter of the request recieved by lldap server and return empty list.@nitnelave commented on GitHub (Nov 18, 2023):
I'm surprised by this behavior. The wildcard should be translated into a substring filter, which is supported.
Can you add the LLDAP verbose logs of receiving/replying to the query?
@ctaoist commented on GitHub (Nov 18, 2023):
I send a query
(mail=*@example.com)when adding a breakpoint atgithub.com/lldap/lldap@2ca5e9e720/server/src/infra/ldap_handler.rs (L787)and the filter is:
As we seen, that the
*was discard.@nitnelave commented on GitHub (Nov 18, 2023):
That actually seems perfectly fine: it's a substring filter that means "ends with @example.com"
Do you have the verbose LLDAP logs for the query?
@ctaoist commented on GitHub (Nov 18, 2023):
It finally returns the empty search result even if there has many records ending with
@example.comWhen I change the query to
(mail=certain@example.com), the value of the filter at the breakpoint location would becertain@example.com, and It can return right search result.verbose:
There was no new debug output when I send search queries.
@nitnelave commented on GitHub (Nov 18, 2023):
If there's no new debug output, it's because no query reached the server: we log something for every query. Is there a cache involved, maybe?
I'd really need to see the logs of the query with the substring filter
@ctaoist commented on GitHub (Nov 19, 2023):
There would be debug output until shutting down the lldap progress by using
Ctrl-c.verbose:
The error message is
Unsupported group attribute for substring filter: \"mail\"atget_groups_listfunction.I have already set
ignored_group_attributesinlldap_config.toml:I use the python3 ldap3 as my ldap client for test:
If I change base_dn from
dc=example,dc=comtoou=people,dc=example,dc=com, it works fine. I am very sorry about that I am a newer with ldap.BTW, the time in debug output is utc time insdead of local time.
@nitnelave commented on GitHub (Nov 19, 2023):
Oh, I see what's happening: the query works fine and finds the right users,
but since the base DN is broad it also looks for groups and runs into an
error (substring for email is not supported for groups). That aborts the
whole query.
It should be easy to fix. And yes, as you found out, changing the base DN,
or adding a (objectClass=person) to the query would solve the problem.
On Sun, 19 Nov 2023, 05:37 ctaoist, @.***> wrote:
@ctaoist commented on GitHub (Nov 20, 2023):
Thanks a lot. I closed this issue.
@nitnelave commented on GitHub (Nov 20, 2023):
I'll reopen since it shouldn't return an error.
@pixelrazor commented on GitHub (Nov 20, 2023):
What's the intended behavior here? both user and group search is done, and only one fails, log that failure as warning then return the successful results?
@nitnelave commented on GitHub (Nov 20, 2023):
Yes, I'm thinking more generally that an attribute failure for either users
or groups, when we search for both, should not be an error.
On Mon, 20 Nov 2023, 15:46 Austin Alvarado, @.***>
wrote: