Open NSeydoux opened 4 years ago
Couple of relevant clues below.
solid-auth-client.bundle.js
, which loads solid-auth-client by placing it in window.solid.auth
.solid-query-ldflex.bundle.js
, which loads LDflex for Solid (with Comunica) by placing it in window.solid.data
.solid-query-ldflex.bundle.js
itself expects solid-auth-client
to be at window.solid.auth
.window.solid
namespace facilitates webpack-less development. I don't know to what extent this is still important and we want to keep doing this (@ajacksified?). But there is some appeal to just including those <script>
tags and getting solid.auth
and solid.data
and you can just start hacking in the browser.solid-query-ldflex.bundle.js
. Namely, we are webpacking a couple of things away that either a) aren't used at runtime, or b) have a native browser equivalent.
@trust/webcrypto
by the browser's window.crypto
.@trust/webcrypto
replaced by window.crypto
.So, very long story short: my guess is that something is using certain crypto functionality that has been webpacked away.
Note in general that the webpack substitutions were very specifically tailored to solid-auth-client
, and they might simply not be valid for solid-auth-fetcher
.
How to resolve this: start by not making any webpack substitutions, and gradually add them until something breaks, then you've found the culprit.
This should give you some clues for detective work; what I'd still like to know is which library makes the createSign
call.
Oh and I bet it's this (deliberately incomplete) shim biting us: https://github.com/solid/query-ldflex/blob/v2.11.1/browser/crypto.js
Note that this file is shimming the Node.js crypto
library, which is different from the window.crypto
library.
I hope that solid-auth-fetcher is written using (a shim for) window.crypto
(@jaxoncreed?), since browser shims of Node.js crypto
tend to be quite big and thus undesired, whereas with Node.js shims of browser window.crypto
, the size is much less of an issue.
Oh and I bet it's this (deliberately incomplete) shim biting us
It most definitely is https://github.com/solid/query-ldflex/blob/v2.11.1/webpack/webpack.common.config.js#L30-L31
because when you do
comment out line 24 ('@solid/query-ldflex': ['solid', 'data']
you bypass that substitution.
I really hope we don't need to include all of Node crypto
in the browser, because that's huge.
You're right, commenting out that exact substitution resolves the issue. I'll see what can be done to shim the required functions.
@NSeydoux That part is optional though; it's only for size reduction. Probably non-trivial to fix.
When using a fork of the demo app updated to use
solid-auth-fetcher
instead ofsolid-auth-client
(available here ), the demo app only works ifwebpack
isn't configured to exclude@solid/query-ldflex
. Otherwise, thecrypto
object isn't resolved properly (?), and an errora.createSign is not a function
is thrown.The confusing part is that the error only manifests when logged in.
How to reproduce
Clone https://github.com/inrupt/react-components/tree/feature/experimental-auth-upgrade
npm ci
npm run start
Go to
http://localhost:8080
There should be no problem yet
Create an account on
https://dev.inrupt.net
(there is a certificate issue with the created domain, it should be resolved soon)Log in to this account from
http://localhost:8080
The error will appear where the user name should be displayed, and if you refresh the page, the same error will be shown instead of Ruben's name and home page. If you log out, and refresh again, the error disappears. Screencast.
Stop the app
In
webpack/webpack.common.config.js
, comment out line 24 ('@solid/query-ldflex': ['solid', 'data'],
)npm run start
Log in again
Now, the username is properly displayed. There might be a network error on Ruben's profile, but that's an unrelated, known issue.
Version information
Additional information
@solid/query-ldflex
version that we depend on is also a fork, managed as a git dependency.