ZendHQ 3.2.0

New features

  • Account lockout and login throttling for local RBAC accounts.

    Local ZendHQ accounts are now protected against brute-force password guessing. After a configurable number of consecutive failed logins an account is permanently locked (zendhqd.session.max_failed_login_attempts, default 5, range 3..10, cannot be disabled), and each failed login imposes an exponentially growing cool-down during which further attempts are refused (initial delay zendhqd.session.initial_throttle_delay, default 500ms, range 100..3000 ms). A successful login resets the counter.

    Unlock a locked account with zendhqctl access user unlock , or reset its password with zendhqctl access user password (which also unlocks it and resets the counter). The lock state, failed-attempt count, and last failed-login time are shown by zendhqctl access user print. Because host-local zendhqctl writes the RBAC database directly, it is the recovery path even for a locked default admin user.

    Lockout and throttling are enforced per account, not per client address. LDAP and OpenID Connect accounts are unaffected.

  • Forensic logging of failed client logins.

    Every failed client authentication now produces a single warning recording the attempted user name, the authentication backend, the client connection (transport and peer address/port, or a marker for local-socket clients), and a short failure reason (invalid-credentials, locked, throttled, no-password, ...). For WebSocket clients behind a reverse proxy, the client-supplied X-Forwarded-For, X-Real-IP, and Forwarded headers are also included and clearly labelled as untrusted. This information is for logging only and is never used in a lockout or throttling decision.

  • Timezone for recurring Job Queue jobs.

    Recurring (cron) jobs can now be given an IANA timezone, for example America/New_York, so that their schedules follow that zone's daylight saving time rules instead of always being evaluated in UTC. The cron expression is matched against wall-clock time in the selected zone, and the resulting execution time is stored and reported in UTC.

    Across a daylight saving transition, local times that do not exist because the clock jumps forward are shifted to the next valid instant, and local times that occur twice because the clock jumps back run on the first occurrence only.

    Every queue and every recurring job carries a timezone, defaulting to UTC. The value is resolved when a queue or job is created, consistent with every other Job Queue default: the new zendhqd.jobqueue.timezone directive (default UTC) supplies the default for new queues, a queue's default is copied onto the recurring jobs created in it, and a job can carry its own value. Changing a configuration directive or a queue default afterwards does not affect queues or jobs that already exist. One-shot jobs have no schedule to evaluate and never carry a timezone.

    Behavior is unchanged for existing installations. Schedules were already evaluated in UTC, and the database upgrade sets UTC on the queues and recurring jobs it finds.

    Set the timezone through the JSON-RPC jq namespace: schedule.timezone on jq.add_job and jq.update_job, and job_defaults.timezone on jq.add_queue and jq.update_queue. An omitted member leaves the current value unchanged, while an explicit null re-inherits the value from the level above. Invalid IANA identifiers and the empty string are rejected with an error. The attribute applies to recurring jobs only.

    The PHP API carries the same capability. ZendHQ\JobQueue\RecurringSchedule takes an optional timezone as its second constructor argument and reports it through the new getTimezone(), and ZendHQ\JobQueue\QueueDefinition takes a queue-level default as its fourth constructor argument with the new getDefaultTimezone() and setDefaultTimezone(). Both accept the IANA identifier as a string or as a \DateTimeZone, and both report it back as a ?string. Existing callers are unaffected: the new arguments are optional.

    Only a region identifier is accepted from a \DateTimeZone. PHP also allows UTC offsets (+02:00) and abbreviations (CEST); those are rejected, because they carry no daylight saving rules and so cannot do what the timezone exists for. Passing null to the constructors means inherit, and leaves a queue's existing default alone; setDefaultTimezone(null) clears a queue's default so that it re-inherits the configured one. Because the daemon resolves the precedence when a job or queue is written, the getters report the timezone that actually applies once the object has been read back. Scheduling a job or creating a queue with a timezone against a ZendHQ daemon older than 3.2 raises an InvalidArgument exception rather than silently dropping it.

    The attribute is carried over zend-rpc and is only sent to PHP extensions that have negotiated the ZendHQ 3.2 API version or newer. The legacy ZeroMQ protocol does not carry it at all, so older PHP extensions keep working unchanged.

Changes

  • Local RBAC passwords are now stored more securely.

    Passwords for local ZendHQ RBAC accounts are now hashed with a per-user random salt using PBKDF2-HMAC-SHA256. Existing databases are upgraded automatically: on first run, stored passwords are migrated to the new format with no loss of access — users keep their current passwords and no administrator action is required.

  • The hard-coded default admin password has been removed.

    A freshly installed admin user now has no password and cannot log in until one is set. Set the initial password with zendhqctl access user password admin, or provide the ZENDHQ_DEFAULT_PASSWORD environment variable to the daemon (the value becomes the admin password on the next start where the user has no password yet — useful for unattended and container deployments).

    Upgrade impact: installations that relied on the implicit zendphp default are locked out after upgrading and must set the admin password using one of the methods above. The daemon logs a warning on start when the default admin user has no password. The deprecated session.auth_token_hash directive is still honoured as an explicit override when the admin user has no password in the RBAC database.

Bug fixes

  • Fixed a memory leak in the ZendHQ daemon where the data of a PHP request that never completed was kept forever. The daemon collects request metadata, server variables, Z-Ray messages, POST data, response bodies and code-trace state for every request, and released it only when the PHP extension reported the end of the request. That report never arrives when the PHP worker dies mid-request or the connection to the node is lost, so on a busy or unstable node memory grew without bound; a request being code traced also left an open dump file handle and an orphaned partial dump on disk.

    The daemon now drops a request that has been in progress for longer than zendhqd.php_request_timeout (default 10 minutes), and anything that arrives for a request after that is rejected. The timeout must be longer than the longest request a node can produce; a request that outlives it is treated as dead and its data, including an in-progress code trace, is discarded.

New API and database schema versions

  • zend-rpc API version is now 20260811.
  • JSON-RPC session namespace API version is now 1.15.
  • JSON-RPC jq namespace API version is now 1.6.
  • User database schema version is now 2.1. On first run, existing bare SHA-256 password hashes are migrated in place to salted PBKDF2 hashes, and the user_users table gains the is_locked, last_failed_login_sec, and failed_count columns used for account lockout and login throttling.
  • Job Queue database schema version is now 2.5. The jobqueue_queues table gains a job_timezone column and the jobqueue_jobs table gains a timezone column. Both are set to UTC on the existing queues and recurring jobs, which is the zone their schedules were already evaluated in. One-shot jobs keep no timezone.