You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The attachment endpoint is going through a code path that does not have a proxy-handling method at this time,
Steps To Reproduce
The only restriction is that HTTP normally goes through a proxy, so for normal sites, the internal DNS does not provide resolution. For this reason I locally cannot nslookup Bitwarden Web Vault either, even though I am able to connect to it with HTTPS through the proxy.
For the blob storage host, the proxy is not attempted to be hit. The logs are from my machine-local proxy, (px in this case, similar to proxydetox and the like), so it should show all attempts.
But I looked a bit at the CLI code. I might be off as I have only the GitHub code without docs and not much TS experience, but I still think it’s a CLI thing. Let me try to explain. If I am possibly correct, then:
bw create attachment eventually calls this method:
fileUploadService.uploadCipherAttachment à azureFileUploadService.upload à azureFileUploadService.azureUploadBlob (my file is small)
The last method then simply calls global fetch, without any proxy configuration:
So my conclusion: Only the api service uses a proxy, but not the azure upload service. This also becomes a more likely conclusion if I search the Bitwarden code for the proxy library https-proxy-agent:
It is only used in two versions of the NodeApiService deriving from ApiService. But nowhere near the Azure stuff.
Expected Result
Attachment endpoint would have a proxy-handling method and not drop the attachment
Actual Result
From what I can see, it looks like the attachment endpoint is going through a code path that for some reason does not have a proxy-handling method at this time.
Screenshots or Videos
No response
Additional Context
No response
Operating System
Linux
Operating System Version
No response
Shell
PowerShell
Build Version
2023.12.0
Issue Tracking Info
I understand that work is tracked outside of Github. A PR will be linked to this issue should one be opened to address it, but Bitwarden doesn't use fields like "assigned", "milestone", or "project" to track progress.
The text was updated successfully, but these errors were encountered:
Issue
The attachment endpoint is going through a code path that does not have a proxy-handling method at this time,
Steps To Reproduce
The only restriction is that HTTP normally goes through a proxy, so for normal sites, the internal DNS does not provide resolution. For this reason I locally cannot nslookup Bitwarden Web Vault either, even though I am able to connect to it with HTTPS through the proxy.
For the blob storage host, the proxy is not attempted to be hit. The logs are from my machine-local proxy, (px in this case, similar to proxydetox and the like), so it should show all attempts.
But I looked a bit at the CLI code. I might be off as I have only the GitHub code without docs and not much TS experience, but I still think it’s a CLI thing. Let me try to explain. If I am possibly correct, then:
bw create attachment eventually calls this method:
https://github.com/bitwarden/cli/blob/master/src/commands/create.command.ts#L88
…ending up here to do the upload:
If I follow this call here:
https://github.com/bitwarden/jslib/blob/master/common/src/services/cipher.service.ts#L691
… I see multiple HTTP relevant calls (same as in proxy logs):
Note the different services used in lines 712 (apiService) and 714 (fileUploadService).
Drilling deeper, the api service is explicitly showing code to deal with a proxy:
apiService.postCipherAttachment à apiService.send à apiService.fetch à apiService.nativeFetch
Now this method has an overload in NodeApiService.nativeFetch (injected in bw.ts) , adding proxy support!
https://github.com/bitwarden/jslib/blob/6008a03395989060e984f6bc331642367ac1ab79/node/src/services/nodeApi.service.ts#L36
On the other hand fileUploadService is defined here, without injected overloads:
https://github.com/bitwarden/jslib/blob/master/common/src/services/fileUpload.service.ts
The sequence here is:
fileUploadService.uploadCipherAttachment à azureFileUploadService.upload à azureFileUploadService.azureUploadBlob (my file is small)
The last method then simply calls global fetch, without any proxy configuration:
So my conclusion: Only the api service uses a proxy, but not the azure upload service. This also becomes a more likely conclusion if I search the Bitwarden code for the proxy library https-proxy-agent:
https://github.com/search?q=org%3Abitwarden%20https-proxy-agent&type=codeConnect your Github account
It is only used in two versions of the NodeApiService deriving from ApiService. But nowhere near the Azure stuff.
Expected Result
Attachment endpoint would have a proxy-handling method and not drop the attachment
Actual Result
From what I can see, it looks like the attachment endpoint is going through a code path that for some reason does not have a proxy-handling method at this time.
Screenshots or Videos
No response
Additional Context
No response
Operating System
Linux
Operating System Version
No response
Shell
PowerShell
Build Version
2023.12.0
Issue Tracking Info
The text was updated successfully, but these errors were encountered: