-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
[identity] Adding extensions API, identity-vscode, and identity-cache-persistence #15384
[identity] Adding extensions API, identity-vscode, and identity-cache-persistence #15384
Conversation
* [identityg Remove machine-code-dependent codepaths * Linter fixes * Disable broken perf test * Added missing import back
"extends": "../../../tsconfig.package", | ||
"compilerOptions": { | ||
"target": "es6", | ||
"lib": ["DOM"], |
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.
Persistance will, for sure, not work on browsers 🤔 I wonder if we should preemptively remove any browser-related logic or configuration.
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.
This ends up being required to build the tests, which import from identity sources. Identity uses lib: DOM
, so we need it here for the same reason.
Ok ok! I like how this is looking. We could get something like this merged and work together on the remaining tasks. For that, I propose the following:
Let me know what you think 🌞 |
When I say that we can get something like this merged, I don’t mean today. What I mean to say is that: draw a line eventually, and make sure that what couldn’t get in is expressed in the form of issues so that we can follow up together. |
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.
I'm glad we're splitting up identity! A few thoughts along the way, mostly I am confused by global object magic now that we're using an explicit function call to activate extensions.
"sideEffects": false, | ||
"dependencies": { | ||
"@azure/core-auth": "^1.3.0", | ||
"@azure/identity": "^2.0.0-beta.4", |
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.
It feels a little weird to me that the extension depends on the base lib it is extending -- is this for interfaces?
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. It's probably not required for VSCode anymore, but it is required for cache-persistence because it's where we get the options type for the cache from.
// @public (undocumented) | ||
const persistence: unique symbol; | ||
|
||
export default persistence; |
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.
should this be a function, so that the library can receive optional configuration at composition time? I could see this being useful for skipping platform detection in some cases
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.
In the new model without the symbolic stuff, this is already a function that takes a "context". Currently, neither of the extensions are equipped to take any configuration options, so do you think we could revisit this idea in a future beta if there's a clearer picture? There isn't any reason that two extension packages couldn't export different shapes, i.e. one package exports an extension directly and the other exports an extension factory that accepts options.
"extends": "../../../tsconfig.package", | ||
"compilerOptions": { | ||
"target": "es6", | ||
"lib": ["DOM"], |
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.
similarly, this shouldn't work in the browser, yeah?
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.
For vscode
it's fine. For cache-persistence
it is required to build the tests, which reach into the identity source code during the build.
…al.ts Co-authored-by: Jeff Fisher <xirzec@xirzec.com>
… other than Node 14
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.
Awesome!! This is a great change and I'm so happy you've landed it.
Now if we can just get identity onto corev2... 😉
"rules": { | ||
"@azure/azure-sdk/ts-package-json-module": "off", | ||
"@azure/azure-sdk/ts-modules-only-named": "off", | ||
"@azure/azure-sdk/ts-package-json-engine-is-present": "off" |
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 you file an issue to fix the linter?
sdk/identity/identity-cache-persistence/samples-dev/extension.ts
Outdated
Show resolved
Hide resolved
Update readme.md (Azure#15384)
This PR introduces an extension API for
@azure/identity
:The extension API is based on passing a function that receives a control interface to set certain, sanctioned properties within the MSAL internals. In the first case, the only option exposed is to set a cache plugin. The function can also run any other arbitrary initialization logic it requires.
There are two first-party extension packages:
@azure/identity-vscode
, providesVisualStudioCodeCredential
and an extension that will add it to the default credentials ofDefaultAzureCredential
@azure/identity-cache-persistence
registers a CachePlugin to the underlying MSAL flows, allowing some credentials (those based on public client) to utilize persistent token storage based on the host platform's secret management capabilities (DPAPI on windows, keychain on macOS, and libsecret on Linux).Items:
ICachePlugin
in the public API surface (through the extension API), but it may be beneficial to do so to enable future scenarios such as distributed caching.identity
package API surface and duplicating the logging code, but this isn't desired. A code-sharing approach or common core package is required to remove this leak.