http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9811
--- Comment #46 from Galen Charlton <[email protected]> --- I've spent a bit of time with the current patch series, and I've *not* been able to reproduce the problem where going to members/member.pl induced DataTables to try loading the entire patron database. Chris, Owen, could you try again? I'd be particularly interested to know exact browser versions if you're still encountering the problem. Looking at the code, I do see a place in C4/Utils/DataTables/Members.pm where some defensive coding is in order: my $limit; if(defined $dt_params->{iDisplayStart} and defined $dt_params->{iDisplayLength}) { # In order to avoir sql injection $dt_params->{iDisplayStart} =~ s/\D//g; $dt_params->{iDisplayLength} =~ s/\D//g; $limit = "LIMIT $dt_params->{iDisplayStart},$dt_params->{iDisplayLength}"; } The problem is that if iDisplayStart is never passed as a CGI parameter (because of a DataTables bug or some unrelated JavaScript bug interfering with the proper initialization of the DataTables object), the patron query will be unlimited. To avoid that, a LIMIT clause should *always* be added to the patron query, with sensible default values if iDisplayStart and/or iDisplayLength are not supplied. 0 and 20, respectively, I'd say. We may also want to consider hardcoding an absolute cap (say 100?) on iDisplayLength. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
