ManticoreSearch Publishes Detailed Checklist for Enabling Authentication in Production
ManticoreSearch has published a comprehensive checklist for implementing authentication in production environments. The guide warns that the “set and forget” approach rarely works and outlines a structured process for enabling auth while minimizing disruption.
The document distinguishes between three main topologies: standalone nodes, setups with distributed tables and remote agents, and replication clusters. Each topology requires different preparation steps before authentication is activated.
Inventory and Preparation
Before any configuration changes, administrators are instructed to inventory every client accessing Manticore Search, including search frontends, data-loading workers, cron jobs, BI dashboards, and backup scripts. For each client, teams must record the protocol, target tables, and required permissions.
Additional checks include confirming whether the deployment uses RT-mode or plain-mode, verifying the pid_file setting, and ensuring all nodes support the same authentication protocol. Backups of the data directory, configuration files, manticore.json, and any existing authentication store are mandatory.
User Creation and Least Privilege
The checklist emphasizes creating users for specific tasks rather than broad access. Examples include separate accounts for read-only search operations, data ingestion, schema migrations, and security administration. Each user receives only the minimum rights required, such as GRANT read ON 'products' or GRANT replication ON 'posts'.
Administrators are advised to test both allowed and denied actions for every account. Bearer tokens returned by CREATE USER or TOKEN commands must be stored securely and never left in logs or command history.
Staging Tests and Production Rollout
Testing must first occur in a staging environment that mirrors the production topology. Configuration examples are provided for both RT-mode (auth = 1) and plain-mode (auth = /var/lib/manticore/auth.json).
For production rollout, the guide recommends performing the change inside a planned maintenance window. After enabling authentication, all clients without credentials will be rejected. Teams must update SQL connections with usernames and passwords and configure HTTP clients to use either Basic authentication or Bearer tokens.
Special procedures exist for distributed and replication scenarios to ensure identical authentication stores are deployed across nodes and that cluster users are correctly registered before nodes are restarted.
Related articles
WhatsApp Web Gains Native Audio and Video Calling with Screen Sharing and Device Switching
WhatsApp, owned by Meta, is rolling out audio and video calling directly in its web version, eliminating the previous need for a separate desktop application. The update introduces a Calls tab with call history and favorite contacts, along with screen sharing and reactions that match most desktop app capabilities. Calls can now seamlessly transfer between devices without disconnection, allowing users to start a conversation in a browser and continue it on a smartphone. Group calls gain waiting rooms where the link creator can require manual approval for entry, useful for professional meetings. Additional improvements include background noise suppression, faster transition to HD video quality, and the ability to call users via usernames across platforms without sharing phone numbers.
Manticore Search Adds Built-in Authentication and Authorization Starting with Version 27.1.5
Manticore Search has introduced native authentication and authorization capabilities for SQL over MySQL, HTTP/HTTPS endpoints, and replication operations. The feature distinguishes between authentication, which identifies the requester, and authorization, which determines permitted actions such as read, write, schema, replication, and admin. Users can enable the feature via the auth directive in the searchd section of the configuration file, supporting both RT mode with auth.json storage and plain mode with an explicit path. Initial setup requires creating an administrator account, after which additional users can be managed through SQL commands like CREATE USER, GRANT, TOKEN, and SET PASSWORD. The system supports mysql_native_password, HTTP Basic authentication, and Bearer tokens, with mandatory SSL or HTTPS recommended for credential transmission. Detailed logging, permission checks, and phased rollout guidance are provided to minimize disruption in production environments.
88% of Enterprises Run AI Agents but Fewer Than 10% Generate Profits, Ronglian Cloud Reports at WAIC Forum
At the 2026 World Artificial Intelligence Conference, Ronglian Cloud highlighted that while 88% of companies have deployed internal AI Agents, fewer than 10% have achieved meaningful revenue from them. The company, which originated from call center and contact platform services serving tens of thousands of enterprises, organized the fourth WAIC Enterprise Agent Forum focused on evolution and commercial landing. Executives from retail, finance, and electronic signature sectors emphasized that buyers now demand proven ROI rather than token consumption metrics or experimental features. Ronglian Cloud outlined a four-stage maturity model ranging from basic Copilot assistance to fully autonomous business loops, noting most organizations remain stuck between stages two and three. The firm is shifting its own model toward effect-based payments and KPI-driven Agent performance in scenarios such as collections and private-domain operations, where one Agent can manage hundreds of thousands of customers at a fraction of human cost.
OAuth Authorization Server Built Without Storing User Profiles
The article details the evolution of an OAuth Authorization Server that deliberately avoids storing user profiles, relying instead on external identity providers for authentication. It addresses three core constraints: hundreds of dynamically created isolated APIs, a public SPA client without a BFF, and the inability of resources to query the AS on every request. The design separates concerns so the AS handles only clients, tenants, grants, audiences, scopes, keys, sessions, and token issuance while the Main API owns profiles and roles. Tokens are managed securely inside a Service Worker using a custom FedCM grant, eliminating races across tabs and reducing XSS exposure. The approach minimizes blast radius, simplifies compliance, and keeps the AS replaceable without affecting product domain logic.