Packing issue with `solid-auth-fetcher`

[NSeydoux]

When using a fork of the demo app updated to use solid-auth-fetcher instead of solid-auth-client (available here ), the demo app only works if webpack isn't configured to exclude @solid/query-ldflex. Otherwise, the crypto object isn't resolved properly (?), and an error a.createSign is not a function is thrown.

The confusing part is that the error only manifests when logged in.

How to reproduce

1. Clone https://github.com/inrupt/react-components/tree/feature/experimental-auth-upgrade

2. npm ci

3. npm run start

4. Go to http://localhost:8080

5. There should be no problem yet

6. Create an account on https://dev.inrupt.net (there is a certificate issue with the created domain, it should be resolved soon)

7. Log in to this account from http://localhost:8080

8. 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.

9. Stop the app

10. In webpack/webpack.common.config.js, comment out line 24 ('@solid/query-ldflex': ['solid', 'data'],)

11. npm run start

12. Log in again

13. 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

• Node.js Version: v12.12.0
• npm Version: 6.14.4
• OS: Ubuntu 18.04-
• Browser: Firefox 77

Additional information

• The @solid/query-ldflex version that we depend on is also a fork, managed as a git dependency.

[RubenVerborgh]

Couple of relevant clues below.

• The overall demo setup is as follows:
  • It uses the compiled solid-auth-client.bundle.js, which loads solid-auth-client by placing it in window.solid.auth.
  • It uses the compiled 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.
• There are several reasons for using such compiled drop-in scripts:
  • On the one hand, the 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.
  • On the other hand, specifically for the demo, it means that only the (very small) React code has to be compiled (11kB), and not the much heavier auth client (129K) and LDflex with Comunica query engine and all associated RDF parsers (1.0M).
• Note that there is no inherent necessity for the demo to do things this way. We could just webpack the whole thing and it will also work (and likely not be broken then actually).
• Now we have applied some tricks to reduce the size of 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.
  • Specifically relevant for this case is that we replace the (incomplete and not to be reused) Node.js polyfill @trust/webcrypto by the browser's window.crypto.
• Now the Solid React components can also be built as a bundle .
  • However, when building this bundle, the browser export of solid-auth-client is used. So solid-auth-client isn't fully built again, we just use the version that is already built and include it as-is.
    • Now that browser version will have @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.

[RubenVerborgh]

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.

[RubenVerborgh]

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.

[NSeydoux]

You're right, commenting out that exact substitution resolves the issue. I'll see what can be done to shim the required functions.

[RubenVerborgh]

@NSeydoux That part is optional though; it's only for size reduction. Probably non-trivial to fix.