await sodium.ready never resolves

[pshc]

Hi all!

I can use libsodium-wrappers 0.7.4 just fine in the node console--the sodium.ready promise resolves and everything works as promised.

But if I try to use it in Chrome or in my jest (jsDOM) tests, I get an uncaught exception "TypeError: f is not a function" on column 12449 and the promise just hangs.

[pshc]

Oh, it might be CSP related in the browser:

VM500:1 Refused to connect to 'data:application/octet-stream;base64,AGFzbQEAAAABxQM0YAABf2AEf39...' because it violates the following Content Security Policy directive: "connect-src

Not sure about jest, maybe it's not happy with the webassembly loader either.

[pshc]

If I add data: temporarily to the CSP, the security violation goes away, but I still get the f is not a function error :( Where can I find more information about how the webassembly is loaded?

[jennatuckerdeveloper]

Does version 0.7.5 load for you? I could not get libsodium-wrappers to load in Chrome earlier this year. That problem was resolved here #196. The latest version solved the loading issue.

However, I am now getting this data:application/octet-stream;base64... error. We did not notice this until very recently, although I cannot confirm when it showed up exactly. I get this same error in Firefox, as well. The load error before was only in Chrome.

I am not sure what this CSP error means for the overall behavior of the library. The library does seem to load. I can run sodium.ready. But it does seem like a bad idea to add the directive to the CSP that's necessary to get rid of this error.

[pshc]

Good question--I can't test easily since I've since left the project where I was working on this problem. As the project progressed, I put the libsodium machinery inside a WebWorker, which seemed to have fixed (or at least silenced?) the CSP issue.

But yes I agree, it would be nice if the WebAssembly were shipped as a separate .wasm file or something instead of the data: directive.