Okay, I was totally mistaken - `$keyword_string` is only ever sanitized in the right place (name/name-desc) in master. Yeah, I can rework this to be a bit cleaner as you recommended -- no problem. ++ on this, will be included in next rev.
On Sun, Jul 5, 2020 at 11:51 AM Kevin Morris <kevr.gt...@gmail.com> wrote: > Do name and name-desc now behave exactly the same (see below)? If so, >> this change in behavior should be documented at least. I would have >> expected some more refactoring in construct_keyword_search() and one >> additional parameter being passed here though. >> >> Should we include pkgfuncs.inc.php from aurjson.class.php now? How does >> this currently get imported? >> >> Also, since the code for both name and name-desc are now very similar, >> can we refactor and share most of the code instead of copy pasting? To >> this end, it might be easier to switch the blocks (i.e. check for API >> version first, then check for request type). That would allow us to >> reuse the same assignment to $keyword_string as before and possibly the >> same construct_keyword_search() invocation too. >> > > I noticed an issue with pre-sanitizing $keyword_string as per `master` -- > when searching by maintainer in rpc, a WHERE Username = $keyword_string is > used without wildcards (%...%). As far as I know, wildcards should only be > used in a LIKE expression? Could be wrong, but that's what I thought when > originally modifying `aurjson.inc.php`'s `function search`. Thoughts? > > On Sun, Jul 5, 2020 at 6:33 AM Lukas Fleischer <lfleisc...@archlinux.org> > wrote: > >> On Sun, 05 Jul 2020 at 01:13:25, Kevin Morris wrote: >> > Alright, patch sent; I used `-v1` this time with `git send-email`... I >> > can't find documentation for that switch yet. I've tested basic search >> > through both paths; the only refactoring that needed to be done was to >> > remove the extra "AND (" and ")" from the generic function, and add it >> > where we need it in `pkg_search_page`. Then, we can reuse the same >> > `construct_keyword_search` in rpc. >> >> Thanks for the revision! I added some comments inline. >> >> It's common to not use any versioning for the first revision of a patch >> (e.g. send without -v1) but then start using (-v2, -v3, ...) for >> followup revisions. The -v argument is documented in the >> git-format-patch(1) man page, if you are using git-format-patch and >> git-send-email separately, you need to specify the argument when >> formatting the patch (however, in most cases, you can also run `git >> format patch` directly). >> > > > -- > Kevin Morris > Software Developer > > Personal Inquiries: kevr.gt...@gmail.com > Personal Phone: (415) 583-9687 > > Technologies: C, C++, Python, Django, Ruby, Rails, ReactJS, jQuery, > Javascript, SQL, Redux > -- Kevin Morris Software Developer Personal Inquiries: kevr.gt...@gmail.com Personal Phone: (415) 583-9687 Technologies: C, C++, Python, Django, Ruby, Rails, ReactJS, jQuery, Javascript, SQL, Redux