awslabs
Usage of aws-jwt-verify fails with missing "https.request" and "crypto.createPublicKey"
I had a stab at using LLRT for running an API Gateway Lambda authorizer with the aws-jwt-verify JS lib (I'm one of the maintainers of that) in LLRT and I'd like to report my findings.
Missing https module
aws-jwt-verify uses the Node.js "https" module which leads to an error when importing aws-jwt-verify:
ReferenceError: Error resolving module 'https' from '/var/task/index.mjs'
Interestingly you can plug other HTTP helpers into aws-jwt-verify, such as fetch, which at first I thought would be a solution--but it's not because the static import { request } from "https", even though unused, remains in the aws-jwt-verify code and will trip up usage in LLRT.
Was able to overcome this with some esbuild magic, injecting a stub https module with a non implemented request function, so that the import doesn't fail (and then plugging in fetch instead).
I'm not sure what the best way forward is, but the thought did occur to me that it might be helpful for LLRT to include stubs like that for all Node.js modules, and raise NotImplementedError when calling not implemented functions? At least the static imports work then, and you'd only run into the NotImplementedError if you or the libraries you use actually use those Node.js functions.
Especially for libraries I can see that be of use, since they often do many static imports, in code paths that your code might not actually be using.
Note: aws-jwt-verify uses Node.js https module because it supports older Node versions (from 16 onwards) that do not have fetch onboard yet.
Missing 'createPublicKey' in module 'crypto'
After solving the https import error I ran into: SyntaxError: Could not find export 'createPublicKey' in module 'crypto'
Cannot stub that out so for now my LLRT journey with aws-jwt-verify ends.
Thanks for the LLRT effort!
Crypto module is pretty bare bone right now, it doesn't support much and indeed not the createPublicKey.
Hi @ottokruse thanks for your comments. That's a valid concern. Crypto will reach web-crypto / subtle compliance in the future. In regards to http and https modules that's a different beast as they are heavily dependent on stream support. We have a stream stub (pulled from Node.js) but it's not ported to Rust as the API is huge. We also have a native stream implementation that doesn't have feature parity and is used for child processes. The plan right now is to add this "minimal" stream API for http and https modules in version 1.0 but right now users would have to use build tooling (such as esbuild) to replace them with empty implementations. I know this is not ideal and maybe we should provide a mechanism like you suggested to provide runtime errors at the callsite.
Closing as crypto (aka webcrypto) is now fully supported. Currently RSA cryptos are very slow, this will change when this goes stable: https://github.com/RustCrypto/RSA/releases/tag/v0.10.0-pre.4