-
Notifications
You must be signed in to change notification settings - Fork 2.7k
[v5] Changes to Configuration - CacheOptions (Config #2) #7697
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
base: msal-v5
Are you sure you want to change the base?
Conversation
@@ -171,10 +171,9 @@ export function redirectPreflightCheck( | |||
): void { | |||
preflightCheck(initialized); | |||
blockRedirectInIframe(config.system.allowRedirectInIframe); | |||
// Block redirects if memory storage is enabled but storeAuthStateInCookie is not |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we still want to block redirects with memory storage here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. On redirect, in memory cache is reset and the authentication will forever loop since there is no cache state indicating a previous redirect request is in progress on reload. This check prevents users ever attempting redirect since we cannot support it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM but somebody else should weigh in on whether to block redirects with memory storage
@@ -71,6 +71,9 @@ To faciliate efficient token acquisition while maintaining a good UX, MSAL cache | |||
> :bulb: The authorization code is only stored in memory and will be discarded after redeeming it for tokens. | |||
|
|||
## Warning :warning: | |||
|
|||
**NOTE: `temporaryCacheLocation` is deprecated as of MSAL v5 and will be removed in a future release.** | |||
|
|||
Overriding `temporaryCacheLocation` should be done with caution. Specifically when choosing `localStorage`. Interaction in more than one tab/window will not be supported and you may receive `interaction_in_progress` errors unexpectedly. This is an escape hatch, not a fully supported feature. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We are keeping the docs? I assumed if it is removed, wouldn't it be just removal notice in migration guidance since this branch is V5?
| `storeAuthStateInCookie` | If true, stores cache items in cookies as well as browser cache. Should be set to true for use cases using IE. | boolean | `false` | | ||
| `secureCookies` | If true and `storeAuthStateInCookies` is also enabled, MSAL adds the `Secure` flag to the browser cookie so it can only be sent over HTTPS. | boolean | `false` | | ||
| `cacheMigrationEnabled` | If true, cache entries from older versions of MSAL will be updated to conform to the latest cache schema on startup. If your application has not been recently updated to a new version of MSAL.js you can safely turn this off. In the event old cache entries are not migrated it may result in a cache miss when attempting to retrieve accounts or tokens and affected users may need to re-authenticate to get up to date. | boolean | `true` when using `localStorage`, `false` otherwise | | ||
| `claimsBasedCachingEnabled` | If `true`, access tokens will be cached under a key containing the hash of the requested claims string, resulting in a cache miss and new network token request when the same token request is made with different or missing claims. If set to `false`, tokens will be cached without claims, but all requests containing claims will go to the network and overwrite any previously cached token with the same scopes. | boolean | `false` | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let us ensure we test this, that we never cache claims. I want to make sure we have Loop
who had this bug before, and Teams
who I think are setting this to false
are not broken with v5.
@@ -95,11 +93,8 @@ const msalInstance = new PublicClientApplication(msalConfig); | |||
| Option | Description | Format | Default Value | | |||
| --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- | --------------------------------------------------- | | |||
| `cacheLocation` | Location of token cache in browser. | String value that must be one of the following: `"sessionStorage"`, `"localStorage"`, `"memoryStorage"` | `sessionStorage` | | |||
| `temporaryCacheLocation` | Location of temporary cache in browser. This option should only be changed for specific edge cases. Please refer to [caching](https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-browser/docs/caching.md#cached-artifacts) for more. | String value that must be one of the following: `"sessionStorage"`, `"localStorage"`, `"memoryStorage"` | `sessionStorage` | | |||
| `storeAuthStateInCookie` | If true, stores cache items in cookies as well as browser cache. Should be set to true for use cases using IE. | boolean | `false` | | |||
| `secureCookies` | If true and `storeAuthStateInCookies` is also enabled, MSAL adds the `Secure` flag to the browser cookie so it can only be sent over HTTPS. | boolean | `false` | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Off the topic, but related. Can we make sure the one
cookie we set for KMSI is the only one we manage and add it to the docs under cookies MSAL JS manages..
etc. Also link to the migration guide on the discontinuation of existing cookies.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we make sure we have tests for claimbased caching and inmemory storage blocking redirects? There could be existing ones, just make sure they are comprehensive.
Approving.
This PR updates the CacheOptions for MSAL Browser v5, including:
temporaryCacheLocation
andclaimsBasedCachingEnabled
storeAuthStateInCookie
,secureCookies
, andcacheMigrationEnabled