-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
(LDAP) respect DB limits of arguments in an IN statement #25020
Conversation
/backport to stable20 |
/backport to stable19 |
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
82ffd50
to
6eca8d6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sure
I guess we could make the querybuilder always log a fatal when running with more than 1k ? |
Yep 👍 |
I had this thought briefly, although more in the direction that it would split it up itself. But didn't want to mess with the query and provoke odd behaviour. Logging a fatal makes sense. |
Try to get a big list of users or groups from LDAP (you need to have them), for instance via
php occ ldap:search --limit=3500 ''
. The actual number of users depends on the database in use. When it is too many, you may run intoSQLSTATE[HY000]: General error: 7 number of parameters must be between 0 and 65535
(Postgres) orORA-01795: maximum number of expressions in a list is 1000
(Oracle). Both MySQL/MariaDB and Sqlite do not have a specific limit of arguments, but of total bytes per statement. With 1000 entries (currently limited to 255bytes each) default values are not being exceeded.Background: when fetching users or groups from LDAP we collect the DN and fetch information from the database. In order to avoid a single read operation per entry, we collect them. Normally we do not need to deal with this huge numbers. Although, depending on the perspective, 1000 is already low. This is relevant when all users or groups are being fetched, which might happen. The prominent case for groups is the users page, as they are not paginated.