-
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
[Tables] Create clients from connectionString #10292
Conversation
/cc @HarshaNalluru who worked on this for storage. |
import { SharedKeyCredentialPolicy } from "./SharedKeyCredentialPolicy"; | ||
|
||
/** | ||
* ONLY AVAILABLE IN NODE.JS RUNTIME. |
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 is only in Node.JS today because of the dependency on HMAC? We've been making a push in other libraries to be able to do this HMAC stuff in browser as well (I know Richard recently did some work in the Application Configuration SDK to support this). I'm looking at trying to get us a @azure/core-crypto
library that will expose some of these primitives in a way that would work in node or browsers, so I'd like to know what all is keeping this node today, so we can expose the right set of primitives so we can have code like this work in the browser as well.
If we had support for doing SHA265 HMAC would that be sufficient to get us browser support 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.
Yeah, I think that's the only thing holding us back in this case
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 asked @XiaoningLiu before for other storage libraries. I remember there are more reasons than hmac support for not having connection strings/shared key credential for browsers. Maybe security related. @XiaoningLiu can you confirm?
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 security concern. SharedKey in browser session is almost public. Storage team recommends using SAS or OAuth in browser sessions.
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.
Thanks @jeremymeng for bringing this up. @XiaoningLiu do you have a doc reference about the security issue, that I can include in the comments of this file to make sure people are aware why this is not supported in the Browser?
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.
The SharedKeyCredential has complete access to your account. Putting it in the hands of clients means clients now have the power to do anything including delete all your data, and moreover, other (possibly untrusted 3rd party) code running in the application can exfiltrate the key trivially. Maybe a vague "for security reasons" is sufficient?
import { URL } from "./url"; | ||
|
||
export interface ConnectionString { | ||
kind: "AccountConnString" | "SASConnString"; |
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 these strings have some sort of well understood meaning? Would AccountConnectionString
and SASConnectionString
work better (or alternately since this is already on the ConnectionString
interface, just Account
and SAS
)
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 see that this doesn't end up getting exported from index.ts
, so I'm less concerned about this.
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 is only used to distinguish the connection strings internally, not for the users :)
@@ -2,7 +2,8 @@ | |||
"extends": "../../../tsconfig.package", | |||
"compilerOptions": { | |||
"outDir": "./dist-esm", | |||
"declarationDir": "./types" | |||
"declarationDir": "./types", | |||
"lib": ["dom", "es5", "es6", "es7", "esnext"] |
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 help me understand why this change happened here? I'm especially interested in the dom
addition (and also I don't really understand why we would have libs for es5
, es6
, es7
and esnext
. Shouldn't we pick a specific one (and have it be the oldest one we can use)?
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.
dom
as added to include DOM declarations and be able to work with URL
in url.browser.ts
. The others are not needed so I'm going to remove them.
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.
dom as added to include DOM declarations and be able to work with URL in url.browser.ts.
Of course, that makes sense. Forgot about the special handing around URL
.
@@ -14,8 +14,7 @@ trigger: | |||
pr: | |||
branches: | |||
include: | |||
# TODO: re-enable master pr validation after tables tests are ready | |||
#- master | |||
- master |
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.
Unnecessary to disable/enable PR triggers in your fork, the trigger rules are actually controlled by the target branch anyway, so I suspect this didn't have an impact ;)
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 did disable js - tables - ci
in PR validation. See this PR #10207 which still has this commented out it doesn't trigger js - tables - ci
}, | ||
"homepage": "https://github.com/Azure/azure-sdk-for-js#readme", | ||
"sideEffects": false, | ||
"dependencies": { |
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 we require @azure/tables in here and samples/typescript/package.json?
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.
Yeah, I wasn't adding it because the package is not yet published. However it looks like we can add it here with a local reference. I'll do that 😄 once we publish we can start grabbing it from NPM
@@ -0,0 +1,38 @@ | |||
// Copyright (c) Microsoft Corporation. |
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 think there is a typo in the file name
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.
Good catch 😄
Api Management - make /tenant endpoints ARM compliant in 2020-06-01-preview version (Azure#11549) * Adds base for updating Microsoft.ApiManagement from version stable/2019-12-01 to version 2020-06-01-preview * Updates readme * Updates API version in new specs and examples * Add support in API Management for Availability Zones (Azure#10284) * apim in azs * fix prettier check * PATCH should return 200 OK (Azure#10328) * add support for PATCH returning 200 OK * CI fixes prettier fix CI fixes part 2 * Password no longer a mandatory property when uploading Certificates * add missing x-ms-odata extension for filter support * +gatewayhostnameconfiguration protocol changes (Azure#10292) * [2020-06-01-preview] Update Oauth Server secrets Contract (Azure#10602) * Oauth server secrets contract * fix azureMonitor enum * API Management Service Deleted Services Resource (Azure#10607) * API Management Service Deleted Services Resource * Path fix * Lint + custom-words fixes * Location URI parameter for deletedservices Resource * GET for deletedservices by service name * Remove resourceGroupName from resource path * fixes * schema for purge operation * perttier applied * 204 response code added Co-authored-by: REDMOND\glfeokti <glfeokti@microsoft.com> * OperationNameFormat property added to Diagnostic contract (Azure#10641) * OperationNameFormat property added to Diagnostic contract * add azuremonitor to update contract Co-authored-by: REDMOND\glfeokti <glfeokti@microsoft.com> * [Microsoft.ApiManagement][2020-06-01-preview] Change Network Status response contract (Azure#10331) * Change Network Status response contract * Update examples for network status contract * ApiManagement - tenant/settings endpoints * ApiManagement - tenant/settings endpoints fix * ApiManagement - tenant/settings endpoints fix prettier * ApiManagement - tenant/settings endpoints fix 3 * ApiManagement - tenant/settings endpoints fix 4 * ApiManagement - tenant/settings endpoints fix 5 Co-authored-by: Samir Solanki <samirsolanki@outlook.com> Co-authored-by: maksimkim <maksim.kim@gmail.com> Co-authored-by: promoisha <feoktistovgg@gmail.com> Co-authored-by: REDMOND\glfeokti <glfeokti@microsoft.com> Co-authored-by: RupengLiu <rliu1211@terpmail.umd.edu> Co-authored-by: vfedonkin <vifedo@microsoft.com>
Support 2 kinds of connection strings to instantiate TableClient and TableServiceClient
Docs for Tables Shared Key Authorization: https://docs.microsoft.com/en-us/rest/api/storageservices/authorize-with-shared-key#table-service-shared-key-authorization
Note: Parts of the authorization using Shared Keys are similar to other Storage Services, however Tables has some specific requirements different from Blob, Queues, etc. It may be a good idea at some point to move common building blocks to a common/core package so that each service can compose their own Authorization reusing them. Filed issue #10291 to track this investigation