feat: make subpath optional for reverse proxy prefix - #631
Conversation
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (2)
Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review. WalkthroughReverse-proxy prefixes can now contain only a host, with or without a trailing slash. For these prefixes, override construction retains the configured assets path and omits the generated dynamic route. Configuration updates can remove a matching route generated from the previous subpath prefix while retaining unrelated routes. Tests cover repeated application and switching between host-only and subpath prefixes. Sequence Diagram(s)sequenceDiagram
participant PrefixInput
participant parseReverseProxyPrefix
participant buildReverseProxyOverride
participant updateConfigYaml
PrefixInput->>parseReverseProxyPrefix: Parse host-only prefix
parseReverseProxyPrefix-->>buildReverseProxyOverride: Return host with undefined subpath
buildReverseProxyOverride-->>updateConfigYaml: Provide override without dynamic route
updateConfigYaml->>updateConfigYaml: Retain assets path and update matching prior generated route
Suggested reviewers: Priority: ⬇️ Low Change: Feature Merge Risk: ⚪ Minimal · up to Host-only prefixes and transitions between prefixes appear ready to merge after normal checks. Security Architecture ReviewSecurity architecture risk: 🟡 Moderate · up to Normal prefix switches preserve asset paths, but an interrupted switch to a host-only prefix can leave the configuration and asset path out of sync, and retrying may not repair it. No new security bypass was established. Retained concerns
Security review detailsSecurity Blast Radius
Trust Boundaries and Controls
Resilience and Maintainability Implications
Hardening Proposals
🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
jhelenek
left a comment
There was a problem hiding this comment.
github doesnt have a +1 option, but +1
if you tested, please add test to the description, o/w please test once you merge
|
Yeah sorry got ahead of myself, need to manually test |
|
Updated with testing details. Deployment plan:
|
didn't mean to request changes, just the one comment
|
|
||
| const subpathSeparatorIndex = trimmedReverseProxyPrefix.indexOf("/"); | ||
| if (subpathSeparatorIndex <= 0) { | ||
| if (subpathSeparatorIndex === 0) { |
There was a problem hiding this comment.
Maybe a bit out of the scope of your changes, but would it be helpful to add additional validation to block inputs like https:? The old logic allowed some invalid inputs as well so this isn't really a regression, just something to consider.
1. Makes the subpath optional 2. Makes the automatically setup redirects optional (because we don't need them if no subpath) 3. Updates the apply step able to handle moving to or from a RPP with a subpath Testing details: - Created a section library with a custom pack of pages js - Successfully created a RPP with a subpath (existing behavior): https://www.yext.com/s/5225829/yextsites/168642/pagesets - Successfully generated a section library revision with no subpath (artifact generation operation 01a0ed74-fba3-79c8-a62e-663884bd0052) -- confirmed the artifacts did not have any subpaths. - Not 100% the client's domain configuration so may need to troubleshoot through the actual deployment
|
|
||
| await applyReverseProxy(undefined, parseReverseProxyPrefix("www.brand.com/locations")); | ||
| await applyReverseProxy(undefined, parseReverseProxyPrefix("restaurants.brand.com")); | ||
| await applyReverseProxy(undefined, parseReverseProxyPrefix("restaurants.brand.com")); |
There was a problem hiding this comment.
Can you explain why we are calling the exact same command twice here? What does this accomplish?
There was a problem hiding this comment.
When the reverse proxy is applied as part of the build, the config.yaml is rewritten. This duplicate call tests if the operation is idempotent
Testing details: