New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Angular SSG: Incompatibility between withXsrfConfiguration( ) (HttpClient) & Relative Paths in SSG #55635
Comments
Hi @surajchopra1234, are you using |
Hi @alan-agius4 I am using |
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
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:
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
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 const serverConfig: ApplicationConfig = {
providers: [
provideServerRendering(),
{
provide: XSRF_TOKEN,
useFactory: () => generateXsrfToken()
}
]
}; |
Hi @alan-agius4, Thank you for working on this issue. Backend: Located at Angular App: Running on XSRF Cookie: Domain is set to Proposed Solution:
|
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
// (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
)Anything else?
No response
The text was updated successfully, but these errors were encountered: