Which @angular/* package(s) are relevant/related to the feature request?
platform-browser
Description
After the security fixes around HttpTransferCache especially for this PR #67964
Today we have:
withHttpTransferCacheOptions({
includeRequestsWithAuthHeaders: true,
});
which lets usexplicitly opt into caching requests that contain headers like Authorization and Cookie.
However, requests made with:
are always excluded.
I'm wondering why there isn't a similar opt-in for credentialed requests, for example:
withHttpTransferCacheOptions({
includeRequestsWithCredentials: true,
});
From my perspective, both approaches can return user-specific data:
Authorization header
- Cookies (
withCredentials)
So if a developer explicitly enables includeRequestsWithAuthHeaders, they're already taking responsibility for the security implications. Why not allow the same for cookie-based authentication?
One use case is applications that never cache SSR HTML for authenticated users (for example by sending Cache-Control: no-store). In that setup, the HTML isn't shared between users, so there isn't a risk of another user receiving someone else's TransferState. It would be nice to still benefit from HttpTransferCache and avoid the extra request during hydration.
Is there a specific reason this option doesn't exist? I had be interested also to hear the design decision behind it.
Thank you
Proposed solution
Exposing a separate opt-in for credentialed requests, similar to includeRequestsWithAuthHeaders.
For example:
withHttpTransferCacheOptions({
includeRequestsWithAuthHeaders: true,
includeRequestsWithCredentials: true,
});
Alternatives considered
Currently the only alternative is to manually use TransferState for these requests instead of relying on HttpTransferCache. it can work, but it means duplicating functionality that's already provided by HttpTransferCache and requires custom logic for requests that would otherwise be handled automatically.
Another option is to accept the additional client-side request after hydration, but this removes one of the main benefits of SSR for authenticated pages.
Which @angular/* package(s) are relevant/related to the feature request?
platform-browser
Description
After the security fixes around
HttpTransferCacheespecially for this PR #67964Today we have:
which lets usexplicitly opt into caching requests that contain headers like
AuthorizationandCookie.However, requests made with:
are always excluded.
I'm wondering why there isn't a similar opt-in for credentialed requests, for example:
From my perspective, both approaches can return user-specific data:
AuthorizationheaderwithCredentials)So if a developer explicitly enables
includeRequestsWithAuthHeaders, they're already taking responsibility for the security implications. Why not allow the same for cookie-based authentication?One use case is applications that never cache SSR HTML for authenticated users (for example by sending
Cache-Control: no-store). In that setup, the HTML isn't shared between users, so there isn't a risk of another user receiving someone else'sTransferState. It would be nice to still benefit fromHttpTransferCacheand avoid the extra request during hydration.Is there a specific reason this option doesn't exist? I had be interested also to hear the design decision behind it.
Thank you
Proposed solution
Exposing a separate opt-in for credentialed requests, similar to includeRequestsWithAuthHeaders.
For example:
withHttpTransferCacheOptions({
includeRequestsWithAuthHeaders: true,
includeRequestsWithCredentials: true,
});
Alternatives considered
Currently the only alternative is to manually use TransferState for these requests instead of relying on HttpTransferCache. it can work, but it means duplicating functionality that's already provided by HttpTransferCache and requires custom logic for requests that would otherwise be handled automatically.
Another option is to accept the additional client-side request after hydration, but this removes one of the main benefits of SSR for authenticated pages.