[haxcms-nodejs] Fix app-store auth regression + standardize system API path - #21
Merged
Conversation
The system API base path is now always absolute (/{basePath}system/api/)
mirroring PHP (HAXCMS.php appJWTConnectionSettings forces a leading slash).
Previously Node emitted a relative systemRequestBase which resolved against
the current page URL, producing a site-scoped system endpoint
(/_sites/<name>/system/api/v1/...) when called from a site context. That
worked on Node (which registers site-scoped system routes) but diverged from
PHP and was not standardized.
Regression noticed during post-merge testing: the appStore URL generated by
connection-settings resolved site-scoped on Node vs root-level on PHP.
Co-Authored-By: Oz <oz-agent@warp.dev>
normalizeSiteApiSecurityPolicy now distinguishes siteTokenHeader-only
('site-token-only') from bearerAuth+siteTokenHeader ('authenticated-site').
The app-store GET declares siteTokenHeader alone, so it maps to
'site-token-only' — the handler (generateAppStore.js) validates the site
token against the server-side active user, no bearer JWT required.
Previously the conformance work mapped siteTokenHeader to 'authenticated-site'
unconditionally, which required a bearer-derived userName at the router
(enforceSystemApiSiteTokenPolicy). The front-end appStore fetch sends the
site token but not a bearer JWT, so both backends rejected the call
(Node 403, PHP 401). This restores the original handler-validated behavior.
provider-search (bearerAuth+siteTokenHeader) stays 'authenticated-site' and
is unaffected. No site-spec routes declare siteTokenHeader-only, so the
site API is unaffected.
Co-Authored-By: Oz <oz-agent@warp.dev>
Review or Edit in CodeSandboxOpen the branch in Web Editor • VS Code • Insiders |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Follow-up to merged PR #20. Two regression fixes noticed during post-merge testing of the app-store endpoint.
Changes
Standardize system API path in connection-settings (parity with PHP)
connectionSettings.js: the system API base path is now always absolute (/{basePath}system/api/), mirroring PHP (HAXCMS.phpappJWTConnectionSettingsforces a leading slash). Previously Node emitted a relativesystemRequestBasewhich the browser resolved site-scoped (/_sites/<name>/system/api/v1/...) when called from a site context. That worked on Node (which registers site-scoped system routes) but diverged from PHP and was not standardized.Restore app-store site-token-only auth stance (fix regression)
app.jsnormalizeSiteApiSecurityPolicy: now distinguishessiteTokenHeader-only (site-token-only) frombearerAuth + siteTokenHeader(authenticated-site). The app-store GET declaressiteTokenHeaderalone, so it maps tosite-token-only— the handler (generateAppStore.js) validates the site token against the server-side active user, no bearer JWT required.siteTokenHeader→authenticated-siteunconditionally, which required a bearer-derived userName at the router (enforceSystemApiSiteTokenPolicy). The front-end appStore fetch sends the site token but not a bearer JWT, so the call was rejected (403).provider-search(bearerAuth + siteTokenHeader) staysauthenticated-siteand is unaffected. No site-spec routes declaresiteTokenHeader-only, so the site API is unaffected.Validation
node --checkon both changed files → OKsiteTokenHeaderwithoutbearerAuthRelated
Co-Authored-By: Oz oz-agent@warp.dev