https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42164
--- Comment #6 from Mark Hofstetter <[email protected]> --- Created attachment 204516 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=204516&action=edit Bug 42164: Allow plugins to provide search engines This patch adds the minimum core integration needed to test alternative search engines without putting a proof-of-concept implementation directly into Koha core. Enabled plugins can register Search, QueryBuilder, and Indexer classes through a koha_search_engine method. The SearchEngine system preference then offers the built-in Zebra and Elasticsearch engines together with the engines registered by plugins. The database-backed reference implementation is: https://github.com/HKS3/koha-nm2db-keyword-search It currently depends on normalized MARC tables provided by: https://github.com/HKS3/koha-normalize-marc2db Database architecture and security ---------------------------------- A database-backed search engine also exposes a broader architectural issue. This concerns the MariaDB service account, not a Koha staff or patron account. A standard Koha instance uses one database identity from koha-conf.xml for its normal DBI/DBIx connections, and the Debian installation grants that identity ALL PRIVILEGES on the instance database. The OPAC, staff interface, background workers, command-line tools, upgrades, reports, and plugins consequently use the same highly privileged database identity. The same schema also contains primary records, configuration, denormalized/generated data, transient state, and plugin-owned tables. Koha already keeps some caches and indexes outside MariaDB through Memcached and Zebra/Elasticsearch, so this is not a claim that all cache data is stored in the main database. The limitation is the lack of a general way to assign different connections, schemas, credentials, and data lifecycles to different components. Additional database identities could improve security through least privilege: * An OPAC identity could have SELECT access to public catalogue and availability data, no access to unrelated administrative or acquisition tables, and narrowly scoped write permissions for enabled patron operations such as holds, renewals, suggestions, tags, and account updates. It would not have DDL privileges. It cannot be completely read-only because several OPAC features legitimately write data. * A reports identity could be read-only, ideally against allowlisted views or a read replica so that sensitive patron, authentication, and financial columns can be excluded or masked. * A staff runtime identity could have the DML rights needed for normal staff work but no CREATE, ALTER, or DROP privileges. * A migration identity could hold DDL rights and only be available during installation and upgrades. * Search engines and plugins could use component-specific identities and, where appropriate, separate schemas containing rebuildable data. This would reduce the impact of a compromised OPAC, plugin, or report: the compromised component would not automatically gain access to every table or be able to change the schema. It would also improve auditability and credential rotation. Database permissions would supplement, not replace, Koha's application authorization. The attached patch does not introduce multiple database connections. It makes the search layer extensible so the database-search approach can be evaluated first. Named connections and documented privilege profiles would be a possible follow-up, while retaining the current single-account setup as the compatibility default. Test plan --------- 1. Apply the attached patch to current master and enable Koha plugins. 2. Run: prove t/Koha/SearchEngine.t 3. Confirm Administration > System preferences > SearchEngine still contains Zebra and Elasticsearch. 4. Install and enable the latest NormalizeMARC2DB plugin, then use "Run tool" once to normalize the existing bibliographic and authority records. 5. Install and enable the NM2DBKeywordSearch reference plugin. 6. Return to the SearchEngine preference. Confirm DBSearch is now offered and select it. 7. Search in both the OPAC and staff catalogue. Verify result pages, facets, refinements, year limits, and pagination. 8. From a Koha shell, run the reference comparison test: prove -v /path/to/koha-nm2db-keyword-search/t/nm2db_vs_koha_search.t 9. Disable the NM2DBKeywordSearch plugin and confirm DBSearch is no longer offered as a preference choice. Switch back to Zebra or Elasticsearch before testing normal searches. The reference integration test compares the database-backed result sets with Koha's normal keyword search for representative terms and also checks facets, search-within-results, availability, publication-year limits, and pagination. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug. _______________________________________________ Koha-bugs mailing list -- [email protected] To unsubscribe send an email to [email protected] website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
