Skip to content
This repository has been archived by the owner on Feb 12, 2024. It is now read-only.

Uncaught TypeError: Cannot read property 'generateKey' of undefined #964

Closed
lightninglu10 opened this issue Aug 27, 2017 · 9 comments
Closed

Comments

@lightninglu10
Copy link

lightninglu10 commented Aug 27, 2017

  • Version: ipfs/js-ipfs
  • Platform: AWS EC2 Linux instance
  • Subsystem: Webcrypto, Chrome 60.0.3112.101

Type: Bug

Severity: High

Description: When trying to connect to IPFS on an amazon ec2 instance, I get the error:

Uncaught TypeError: Cannot read property 'generateKey' of undefined.

It seems like it's coming from the webcrypto package. But it's weird because it works locally for me, it's only when I deploy to ec2 that all of a sudden things go haywire.

I also get the error:

Uncaught Error: Callback was already called.

Steps to reproduce the error:

Will put up a website in a second.

@lightninglu10
Copy link
Author

Found the error: it seems like we need to deploy over HTTPS for IPFS to work. @diasdavid can you confirm this is the case?

@daviddias
Copy link
Member

@lightninglu10 HTTP or HTTPS should not be related. Note that the code is running in your browser and dialing to an IPFS node running in Node.js, correct?

What is the version of Node.js running in your EC2 instance?

@lightninglu10
Copy link
Author

lightninglu10 commented Aug 28, 2017

The code is running in my browser but dialing to an IPFS node running in Go.

I think the HTTPS/HTTP is relevant as I only ran into this error:

Uncaught TypeError: Cannot read property 'generateKey' of undefined.

from the browser's native webcrypto
on regular HTTP network. Through HTTPS, I don't get that error.

@daviddias
Copy link
Member

@lightninglu10 is your go endpoint behind a SSL termination proxy? //cc @lgierth who can share some tricks here :)

@daviddias
Copy link
Member

@lightninglu10 is your go endpoint behind a SSL termination proxy? //cc @lgierth who can share some tricks here :)

Do note that if this was really an HTTPS issue, the browser node should fail dialing on the transport and would never get to SECIO (which is where that generateKey happens). I'm intrigued by how you have things set up as I'm not figuring out what is the codepath you are hitting in your particular situation.

@mitra42
Copy link

mitra42 commented Aug 28, 2017

Not sure if they are related but I reported a bug in the shared-editor repo which may be the same one ipfs-shipyard/shared-editing-demo#4 . Note - it occurs in recompiled code, not the one in that repo. That one also only occurs when working remote, but not locally.

@daviddias
Copy link
Member

daviddias commented Aug 28, 2017

TIL that WebCrypto is restringed to HTTPS pages It seems that WebCrypto does require a secure context to run and that is not granted in non HTTPS loaded pages. It has an exception for localhost though.

Apologies @lightninglu10, you are totally right. It is a HTTPS/HTTP issue.

@daviddias
Copy link
Member

Opened a issue to discuss and reach a conclusion for the preferred solution libp2p/js-libp2p-crypto#105

@daviddias
Copy link
Member

Let's track it there

alanshaw pushed a commit to libp2p/js-libp2p-crypto that referenced this issue Jul 4, 2019
This PR adds `crypto-browserify` to the dependencies and replaces `crypto` with `crypto-browserify` when bundled in the browser.

In files that require webcrypto we check to see if it's available. If it is not we require the Node.js implementation (which has `crypto` replaced with `crypto-browserify`) and if it is available then we use the webcrypto version (so we get fast crypto).

Shipping `crypto-browserify` adds to the bundle size:

Current gzipped size: 142,824 bytes
New gzipped size: 214,499 bytes

Difference: **+71,675 bytes**

It's not an insignificant addition so we need to decide whether this is worth it.

If not accepted, we need to add checks when libp2p-crypto methods are called and callback with an appropriate error message. JS IPFS will continue to have issues opened with confusion around this otherwise! See ipfs/js-ipfs#963 ipfs/js-ipfs#964 ipfs/js-ipfs#2153

resolves #105

License: MIT
Signed-off-by: Alan Shaw <alan.shaw@protocol.ai>
MicrowaveDev pushed a commit to galtproject/js-ipfs that referenced this issue May 22, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants