Angular SSG: Incompatibility between withXsrfConfiguration( ) (HttpClient) & Relative Paths in SSG

[surajchopra1234]

Which @angular/* package(s) are the source of the bug?

common

Is this a regression?

Yes

Description

• My backend API resides at api.domain.com

• I'm using the path //api.domain.com/api/product for fetching data within the Angular app. This approach is necessary because withXsrfConfiguration() doesn't function correctly with absolute paths (e.g., https://api.domain.com/api/product).

• While this relative path ( //api.domain.com/api/product ) works properly during runtime, it fails to resolve correctly during SSG build time. This results in no data for the product prerendered page.

• Interestingly, absolute paths do work during SSG, but they prevent the use of withXsrfConfiguration, which is crucial for Cross-Site Request Forgery (CSRF) protection.

• Is there a known workaround to address the incompatibility between withXsrfConfiguration and relative paths in SSG in Angular 17.

• Also, if we use proxies and have a relative URL like /api/product, this might work with withXsrfConfiguration but not in SSG.

Conclusion

• Relative URLs like // (protocol-relative) and / (root-relative) work with withXsrfConfiguration but not in SSG and Absolute URLs work in SSG but not with withXsrfConfiguration.

Please provide a link to a minimal reproduction of the bug

No response

Please provide the exception or error you saw

No response

Please provide the environment you discovered this bug in (run ng version)

Angular CLI: 17.3.2
Node: 21.7.1 (Unsupported)
Package Manager: npm 10.5.2
OS: win32 x64

Angular: 17.3.1
... animations, cdk, common, compiler, compiler-cli, core, forms
... material, platform-browser, platform-browser-dynamic
... platform-server, router

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1703.2
@angular-devkit/build-angular   17.3.2
@angular-devkit/core            17.3.2
@angular-devkit/schematics      17.3.2
@angular/cli                    17.3.2
@angular/ssr                    17.3.2
@schematics/angular             17.3.2
rxjs                            7.8.1
typescript                      5.2.2
zone.js                         0.14.3

Anything else?

No response

[alan-agius4]

Hi @surajchopra1234, are you using withFetch? and which Angular CLI builders are you using?

[surajchopra1234]

Hi @alan-agius4

I am using withFetch and new application builder in angular.

[alan-agius4]

It seems that XSRF does not work for URLs with protocols due the implementation in the framework, see:

angular/packages/common/http/src/xsrf.ts

Lines 100 to 101 in f1e3ec2

	lcUrl.startsWith('http://') ||
	lcUrl.startsWith('https://')

This limitation is due to variations in the cookies set across different origins. However, it doesn't handle the case of a cookie being shared between sub-domains. Can you confirm if this is the type of cookie in your scenario?

Protocol-less URLs, are solely managed by browsers, thus incompatible with environments like Node.js. The browser determines the protocol based on the current page, making this feature nonfunctional on servers. Additionally, the usage of protocol-less URLs has become less common due to various drawbacks:

1. Security Vulnerabilities: Protocol-less URLs pose a risk of "man-in-the-middle" attacks, particularly on HTTP-served sites.
2. Performance Implications: Browsers may encounter delays in loading resources as they determine the correct protocol.
3. Mixed Content Concerns: Integrating protocol-less URLs that load over HTTP within secure HTTPS pages can trigger mixed content warnings in browsers.

On the server side while doing SSG/SSR, the XSRF token currently is being noop'd. see:

angular/packages/common/http/src/xsrf.ts

Lines 74 to 76 in f1e3ec2

	if (this.platform === 'server') {
	return null;
	}

While it's feasible to adjust this behavior for SSR, in the case of SSG, the token will remain undefined. This occurs because there is no request during SSG, preventing retrieval of the cookie from the document or request.

This would require the framework to support a different approach, either by setting an value of the token via an environment variable example XSRF_TOKEN="blabla" ng build or being set in the application as a DI token.

const serverConfig: ApplicationConfig = {
  providers: [
    provideServerRendering(),
    {
      provide: XSRF_TOKEN,
      useFactory: () => generateXsrfToken()
    }
  ]
};

[surajchopra1234]

Hi @alan-agius4,

Thank you for working on this issue.

Backend: Located at api.domain.com

Angular App: Running on www.domain.com

XSRF Cookie: Domain is set to .domain.com, making it accessible from both api.domain.com and www.domain.com

Problem:

• Using relative paths causes the SSG to break, but relative paths are required for XSRF

Proposed Solution:

• Making XSRF work with absolute paths (eg. https://api.domain.com/api/user ) would solve all the issue and allow us to have consistent URLs across SSR, SSG, and client-side browser.

[surajchopra1234]

Workaround:

The workaround is to use absolute paths for GET requests in SSG/SSR, but CSRF protection doesn't require this for GETs (no token needed). Ideally, we'd use relative paths for other HTTP methods (POST, etc.) to enable CSRF protection. These actions don't need SSG as they involve dynamic data.

This workaround makes the URL inconsistent across situations, which can cause problems and be difficult to understand.