Why the WebCron Host and Scheme Must Match the Registered Site Origin
QCTNH validates that the native Joomla WebCron endpoint belongs to the same registered site origin instead of accepting an arbitrary URL supplied alongside the site identity.
Required relationship
- WebCron endpoint scheme must match the registered origin scheme.
- WebCron endpoint host must match the registered origin host under the service’s canonical handling.
- The endpoint path/query must match an accepted native Joomla com_ajax WebCron route.
- The endpoint cannot smuggle an unrelated host through redirects because the worker does not follow arbitrary redirects.
Why this matters
The endpoint contains an operational WebCron credential and the service will call it when work is due. Binding it to the site origin prevents a registration request from making QuantaCade call an unrelated server.
Migration consequence
After a domain or HTTP/HTTPS change, regenerate/verify the route from the new Joomla origin and run Test Connection. Do not keep the old origin while manually entering a different WebCron host.
Security boundary
Why the WebCron Host and Scheme Must Match the Registered Site Origin is part of a deliberately narrow remote-execution boundary. QuantaCade is allowed to call only the registered public Joomla native WebCron route, on the registered origin, using the site’s WebCron credential. Public-IP and exact-route validation keep that service from becoming a general-purpose request proxy.
That boundary is why private/reserved addresses, unexpected query parameters, unrelated paths, and redirect-dependent destinations are rejected rather than “made to work.”
Community Discussion
Want to compare scheduler workflows, share practical tips, or discuss how you use this QCTNH feature? Visit the QC Task Nudge & Health Community. For private support, bug reports, account-specific issues, or feature requests, use the QuantaCade support system.