Skip to content
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

DisableResponseDecompressionPolicy error with electron app using azure sdk from angular renderer #21110

Closed
amrit-moomie opened this issue Mar 30, 2022 · 18 comments
Assignees
Labels
bug This issue requires a change to an existing behavior in the product in order to be resolved. Client This issue points to a problem in the data-plane of the library. customer-reported Issues that are reported by GitHub users external to the Azure organization. needs-team-attention Workflow: This issue needs attention from Azure service team or SDK team Service Attention Workflow: This issue is responsible by Azure service team. Storage Storage Service (Queues, Blobs, Files)

Comments

@amrit-moomie
Copy link

I have a desktop app that uses electron and angular. I am trying to upload the Blob storage using @azure/storage-blob in the angular renderer process. When uploadData method is called library will just crash with following error:

Error: Uncaught (in promise): Error: DisableResponseDecompressionPolicy is not supported in browser environment
Error: DisableResponseDecompressionPolicy is not supported in browser environment

Please note I am using nodeIntegration: true when opening the angular portal like below:

     this.mainWindow = new BrowserWindow({
          webPreferences: {
            nodeIntegration: true
         },
        });

From my understanding is that disableResponseDecompressionPolicy is only available in Node.js but this is a common use case where angular apps running inside an electron shell need to communicate with azure-storage. Can we get more clarity on this issue, whether this is a limit in the SDK and how can angular app inside electron work

old issue: #14025

@ghost ghost added needs-triage Workflow: This is a new issue that needs to be triaged to the appropriate team. customer-reported Issues that are reported by GitHub users external to the Azure organization. question The issue doesn't require a change to the product in order to be resolved. Most issues start as that labels Mar 30, 2022
@azure-sdk
Copy link
Collaborator

Label prediction was below confidence level 0.6 for Model:ServiceLabels: 'Storage:0.5366847,Azure.Core:0.18370384,Azure.Identity:0.06410674'

@maorleger maorleger added Client This issue points to a problem in the data-plane of the library. Storage Storage Service (Queues, Blobs, Files) labels Mar 30, 2022
@ghost ghost removed the needs-triage Workflow: This is a new issue that needs to be triaged to the appropriate team. label Mar 30, 2022
@maorleger
Copy link
Member

@amrit-moomie thank you for creating this issue! I have routed it to the appropriate team for investigation. @EmmaZhu could someone from the storage team take a look?

@EmmaZhu
Copy link
Member

EmmaZhu commented Apr 2, 2022

Storage only uses disableResponseDecompressionPolicy when determined it's Node.js environment in runtime, but seems for Electron it still selects the browser path.

  if (isNode) {
    // policies only available in Node.js runtime, not in browsers
    factories.push(proxyPolicy(pipelineOptions.proxyOptions));
    factories.push(disableResponseDecompressionPolicy());
  }

@jeremymeng , any suggestions how we could deal with this situation?

Thanks
Emma

@amrit-moomie
Copy link
Author

Hi @EmmaZhu
Any update on how this can be resolved?

@jeremymeng
Copy link
Member

@EmmaZhu we could change the browser version of these policy to not throw and just log warning messages. However, if angular app is running our Storage SDK code in the browser path, users might be surprised when their compressed blob get decompressed automatically by the browser when downloading.

@EmmaZhu
Copy link
Member

EmmaZhu commented Apr 26, 2022

Hi @jeremymeng ,

I may understand the issue wrong, please correct me if I'm wrong.

The issue here is: when customer set nodeIntegration: true, isNode which detects the environment in runtime would return true, but the file is picked up in compiling and the compiler thinks it's a browser.

I see we only support disableResponseDecompressionPolicy in Node.JS, because we have no control on whether to decompress response content in Browser environment.

If customer sets nodeIntegration: true, do we have control on on whether to decompress response content? If anyway, we cannot control it, I think maybe ignoring the disableResponseDecompressionPolicy setting with a warning is a good way to go.

Thanks
Emma

@amrit-moomie
Copy link
Author

Hi @EmmaZhu @jeremymeng

Possible to get a fix for this in the coming version?

@jeremymeng
Copy link
Member

I don't know a lot about Electron. It seems that nodeIntegration: true would allow access to nodejs apis. I wonder whether there's a way to let Electron go through our NodeJS code path, then the behavior would not be a surprise.

azure-sdk pushed a commit to azure-sdk/azure-sdk-for-js that referenced this issue Oct 14, 2022
[2022-04-01-preview] Add New Api-version for Microsoft.ApiManagement (Azure#20399)

* Adds base for updating Microsoft.ApiManagement from version preview/2021-12-01-preview to version 2022-04-01-preview

* Updates readme

* Updates API version in new specs and examples

* APIM Auth Servers (Azure#19234)

* APIM Auth Servers

* adding x-ms-identifiers

* removing some weird, invisible special char

* formatting

* oAuth2AuthenticationSettings moved to AuthSettings

* Formatting

Co-authored-by: Milan Zolota <[email protected]>

* API Management Authorization Endpoints (Azure#19615)

* Add blockchain to latest profile

* Add additional types

* add authorizations definitions

* authorizations operations

* add examples

* update readme

* fix examples

* fix linter delete errors

* address CI validation errors

* prettier fix

* update to 2022-04

* fix readme

* Update specification/apimanagement/resource-manager/Microsoft.ApiManagement/preview/2022-04-01-preview/apimauthorizationproviders.json

Co-authored-by: Sean Kim <[email protected]>

* update versions

* Apply suggestions from code review

Co-authored-by: Mark Cowlishaw <[email protected]>
Co-authored-by: Annaji Sharma Ganti <[email protected]>
Co-authored-by: Annaji Sharma Ganti <[email protected]>

* Move Long running Create Operation from Location based to Azure-AsyncOperation Header (Azure#19733)

* azure-asyncOperation

* prettier

* fix(apim): Add missing 'metrics' property to diagnostics contract in 2022-04-01-preview (Azure#20317)

* apim /PUT apis import add translateRequiredQueryParameters (Azure#20333)

* [2022-04-01-preview] Replace resource with proxyresource and TrackedResource (Azure#20461)

* replace resource with proxyresource

* revert to proxyresource

* Add type object to authorization definitions (Azure#20631)

Authorization definitions were missing "type": "object", and this change adds that key/value pair

* Add type object to policy fragment definition (Azure#20585)

* APIM Open ID Connect providers (Azure#20622)

* APIM Open ID Connect providers

* added new proeprties for update

* prettier

* [APIM] Add Nat Gateway (Azure#19990)

* Update apimdeployment.json

* Create ApiManagementCreateServiceWithNatGatewayEnabled.json

* fix typo in file

* Change Nat Gateway property to enum

* modify type of natgateway state

* update property name

* add example reference

* small fix in example

* rename to  outboundPublicIPAddresses

Co-authored-by: Samir Solanki <[email protected]>

* [2022-04-01-preview] MIgrate2Stv2 API (Azure#20504)

* migrate2stv2

* updated to post

* 202 and location

* add body to 202

* remove body from 202

Co-authored-by: Vatsa Patel <[email protected]>
Co-authored-by: Samir Solanki <[email protected]>
Co-authored-by: [email protected] <[email protected]>

* Address Authorizations MissingTypeObject errors (Azure#20919)

* Add forgotten If-Match header (Azure#20920)

* Add forgotten If-Match header

`If-Match` header for the `DeleteAuthorizationAccessPolicy.json file` was forgotten. This change adds the wildcard character for the `If-Match` header for that file.

* Update ApiManagementDeleteAuthorization.json

* Use common types for specs and count as readonly (Azure#21023)

* common types

* count readonly

* Sasolank/more review comments (Azure#21025)

* XML

* proxy to gateway

* Update Authorizations Spec (Azure#21027)

* Update definitions.json

Update wording for PostGetLoginLink endpoint description

* Update apimauthorizationproviders.json

Add 201 response to all Authorization PUT requests

* Updated examples and fixed formatting

There was a formatting issue within apimauthorizationproviders.json, and the Authorization examples needed to be updated with the new 201 responses for creating/updating Authorization entities.

* Add long-running-operation key/value

Added x-ms-long-running-operation: true to Authorization PUT requests

* Remove long-running-operations

* readonly revert (Azure#21050)

* Set  SchemaContract.Document as required. (Azure#20110)

* Updated documentation of the SchemaContract. Server use to return code 500 in case SchemaContract.Document is null. That issue was fixed in the APIM and server will return proper response code.

* Fix AzureApiValidation

* update field with properties

* revert remaining readonly on collection (Azure#21051)

* Change to camel casing for "accesspolicies" (Azure#21070)

* Change to camel casing for "accesspolicies"

* More camel casing updates for access policies

* list example fixed (Azure#21089)

* fix definition (Azure#21110)

* upgrade to v3 for common types (Azure#21109)

* upgrade to v3

* Space

* revert to v2 proxyResource

Co-authored-by: Milan Zolota <[email protected]>
Co-authored-by: Milan Zolota <[email protected]>
Co-authored-by: Sean D Kim <[email protected]>
Co-authored-by: Mark Cowlishaw <[email protected]>
Co-authored-by: Annaji Sharma Ganti <[email protected]>
Co-authored-by: Annaji Sharma Ganti <[email protected]>
Co-authored-by: Tom Kerkhove <[email protected]>
Co-authored-by: Korolev Dmitry <[email protected]>
Co-authored-by: Logan Zipkes <[email protected]>
Co-authored-by: Rafał Mielowski <[email protected]>
Co-authored-by: malincrist <[email protected]>
Co-authored-by: GuanchenIntern <[email protected]>
Co-authored-by: VatsaPatel <[email protected]>
Co-authored-by: Vatsa Patel <[email protected]>
Co-authored-by: [email protected] <[email protected]>
Co-authored-by: Maxim Agapov <[email protected]>
@gingi
Copy link
Member

gingi commented Oct 24, 2022

I have the exact same issue. We use @azure/storage-blob in an Electron web view, and try to use browser-only flows (which is not ideal), but then encounter this error ("DisableResponseDecompressionPolicy is not supported in browser environment") when trying to list storage containers (BlobServiceClient.listContainers()). In addition to addressing this particular issue, it would be helpful to provide guidance on using the Azure Storage SDK in Electron (we use Webpack for bundling, for what it's worth).

@EmmaZhu
Copy link
Member

EmmaZhu commented Oct 25, 2022

Seems the root cause for this issue is: isNode function in our SDK determines it's a node environment, but the bundle still thinks it's a browser and uses the browser version file.

The best fix should be to make isNode and the bundle behavior consistent. But for now, we still don't know how the difference happens.

@EmmaZhu
Copy link
Member

EmmaZhu commented Oct 25, 2022

Hi @jeremymeng ,

If we add a browser version isNode implementation which always returns false, would this cause any potential issues? This way the isNode behavior would be consistent with the bundle way. I'm still worried this may cause other issues we don't know about for now.

Thanks
Emma

@gingi
Copy link
Member

gingi commented Nov 2, 2022

@EmmaZhu: It looks like isNode() works properly within the Electron renderer process (it returns true). But @azure/core-http still uses the browser version of several policies, including DisableResponseCompressionPolicy, which throw this error. It seems to be defined in package.json's "browser" section which is in turn used by rollup. So I'm assuming isNode() isn't being honored.

@EmmaZhu
Copy link
Member

EmmaZhu commented Nov 4, 2022

@gingi :

I think the issue is because: The bundler dectects it's a browserfy environment and choses the browser version DisableResponseCompressionPolicy definition when isNode() is not invoked yet. While in runtime, isNode() is invoked and returns true due to configure of nodeIntegration: true

@gingi
Copy link
Member

gingi commented Nov 18, 2022

Update:

I modified our webpack config to favor the node versions of both @azure/storage-blob and @azure/core-http (we need the latter because of policy enforcements):

    resolve: {
        alias: {
            "@azure/storage-blob":
                "node_modules/@azure/storage-blob/dist/index.js",
            "@azure/core-http":
                "node_modules/@azure/core-http/dist/index.js"
        }
    },

However, I am now facing the error Failed to execute 'fetch' on 'Window': Illegal invocation, which is thrown by:

https://github.com/gingi/azure-sdk-for-js/blob/80949a8a07f168c1e45188f52d9ddf09fffa8edc/sdk/core/core-http/src/nodeFetchHttpClient.ts#L359-L359

Any ideas on how to handle this? I found this possibly related issue.

@amrit-moomie
Copy link
Author

@EmmaZhu
Is it possible to get a workaround or solution to this issue?

@xirzec xirzec added bug This issue requires a change to an existing behavior in the product in order to be resolved. Service Attention Workflow: This issue is responsible by Azure service team. and removed question The issue doesn't require a change to the product in order to be resolved. Most issues start as that labels Mar 31, 2023
@ghost ghost added the needs-team-attention Workflow: This issue needs attention from Azure service team or SDK team label Mar 31, 2023
@ghost
Copy link

ghost commented Mar 31, 2023

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @xgithubtriage.

Issue Details

I have a desktop app that uses electron and angular. I am trying to upload the Blob storage using @azure/storage-blob in the angular renderer process. When uploadData method is called library will just crash with following error:

Error: Uncaught (in promise): Error: DisableResponseDecompressionPolicy is not supported in browser environment
Error: DisableResponseDecompressionPolicy is not supported in browser environment

Please note I am using nodeIntegration: true when opening the angular portal like below:

     this.mainWindow = new BrowserWindow({
          webPreferences: {
            nodeIntegration: true
         },
        });

From my understanding is that disableResponseDecompressionPolicy is only available in Node.js but this is a common use case where angular apps running inside an electron shell need to communicate with azure-storage. Can we get more clarity on this issue, whether this is a limit in the SDK and how can angular app inside electron work

old issue: #14025

Author: amrit-moomie
Assignees: EmmaZhu
Labels:

bug, customer-reported, Client, Storage, Service Attention

Milestone: -

@EmmaZhu
Copy link
Member

EmmaZhu commented May 6, 2023

Hi @jeremymeng ,

Any chance to Iadd a browser version isNode implementation which always returns false, would this cause any potential issues?

Thanks
Emma

Copy link

Hi @amrit-moomie, we deeply appreciate your input into this project. Regrettably, this issue has remained inactive for over 2 years, leading us to the decision to close it. We've implemented this policy to maintain the relevance of our issue queue and facilitate easier navigation for new contributors. If you still believe this topic requires attention, please feel free to create a new issue, referencing this one. Thank you for your understanding and ongoing support.

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Mar 29, 2024
@github-actions github-actions bot locked and limited conversation to collaborators Mar 29, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug This issue requires a change to an existing behavior in the product in order to be resolved. Client This issue points to a problem in the data-plane of the library. customer-reported Issues that are reported by GitHub users external to the Azure organization. needs-team-attention Workflow: This issue needs attention from Azure service team or SDK team Service Attention Workflow: This issue is responsible by Azure service team. Storage Storage Service (Queues, Blobs, Files)
Projects
None yet
Development

No branches or pull requests

7 participants