@fastly/js-compute - npm Package Versions

0.5.11 (2022-11-30)

Changed

• update nodejs supported versions to 16 - 19 and npm supported version to only 8 (5ec70b9)

0.5.10 (2022-11-30)

Changed

• ensure custom cache keys are uppercased (f37920d), closes #318

0.5.9 (2022-11-29)

Added

• add fastly:cache-override module (f433464)
• add geo ip lookup function to fastly:geolocation (24601e5)
• Add Logger constructor to "fastly:logger" module (b4818a2)
• expose fastly loggers via fastly:logger module (2d0bcfe)
• expose the fastly features via 'fastly:' namespaced modules (c06cd16)
• move env function into fastly:env (327b344)

Changed

• Add types for setTimeout, clearTimeout, setInterval, clearInterval (c1ed00c)

0.5.8 (2022-11-28)

Changed

• Allow process.execPath to contain whitespace (caefe51)

0.5.7 (2022-11-24)

Changed

• add missing shebang and executable bit to the binary file (3f0cd69)

0.5.6 (2022-11-24)

Added

• implement setTimeout, setInterval, clearTimeout, and clearInterval (128bca9)

0.5.5 (2022-11-23)

Added

• implement Request.prototype.setCacheKey (457eabe)
• implement support in Response.json/text/arrayBuffer methods for guest provided streams (50cdc44)

Changed

• respond with 500 Internal Server Error when an unhandled error has occured and no response has already been sent to the client (e5982d8)

0.5.4 (2022-09-28)

Added

• Add ConfigStore class (#270)
• Add Dynamic Backends support (#250)
• Improved performance when constructing a ObjectStore instance (#272

Dynamic Backend support

Note: This feature is disabled by default for Fastly Services. Please contact Fastly Support to request the feature be enabled on the Fastly Services which require Dynamic Backends.

This feature makes it possible to use the standard fetch within JavaScript applications.

Dynamic Backends is a new feature which enables JavaScript applications to dynamically create new backend server definitions without having to deploy a new version of their Fastly Service. These backends function exactly the same as existing backends, and can be configured in all the same ways as existing backends can via the Fastly Service configuration.

By default, Dynamic Backends are disabled within a JavaScript application as it can be a potential avenue for third-party JavaScript code to send requests, potentially including sensitive/secret data, off to destinations that the JavaScript project was not intending, which could be a security issue. To enable Dynamic Backends the application will need to set fastly.allowDynamicBackends is to true.

There are two ways to make use of Dynamic Backends within JavaScript projects:

The first way is by omitting the backend property definition on the Request instance. The JavaScript Runtime will then create a Dynamic Backend definition using default configuration options. This approach is useful for JavaScript applications as it means that a standard fetch call will now be possible, which means libraries that use the standard fetch will begin to work for applications deployed to Fastly.

Below is as an example JavaScript application using the default Dynamic Backend option:

// Enable dynamic backends -- warning, this is potentially dangerous as third-party dependencies could make requests to their own backends, potentially including your sensitive/secret data
fastly.allowDynamicBackends = true;

// For any request, return the fastly homepage -- without defining a backend!
addEventListener("fetch", event => {
  event.respondWith(fetch('https://www.fastly.com/'));
});

The second way is by creating a new Dynamic Backend using the new Backend class. This approach is useful for JavaScript applications that want to have full control over the configuration of the new backend defintion, such as only allowing TLS 1.3 and disallowing older versions of TLS for requests made to the new backend.

E.G.

// Enable dynamic backends -- warning, this is potentially dangerous as third-party dependencies could make requests to their own backends, potentially including your sensitive/secret data
fastly.allowDynamicBackends = true;

// For any request, return the fastly homepage -- without defining a backend!
addEventListener("fetch", event => {
  // We are not defining all the possible fields here, the ones which are not defined will use their default value instead.
  const backend = new Backend({
    name: 'fastly',
    target: 'fastly.com',
    hostOverride: "www.fastly.com",
    sslMinVersion: 1.3,
    sslMaxVersion: 1.3,
    sniHostname: "www.fastly.com",
  });
  event.respondWith(fetch('https://www.fastly.com/', {
    backend // Here we are configuring this request to use the newly defined backend from above.
  }));
});

Config-store support and Dictionary deprecated

We have renamed the Dictionary class to ConfigStore, the old name Dictionary still exists but is now deprecated. We recommend replacing Dictionary with ConfigStore in your code to avoid having to migrate in the future when Dictionary is fully removed.

Below is an example application using the ConfigStore class:

async function app(event) {
  const store = new ConfigStore('example')
  
  // Retrieve the contents of the 'hello' key
  const hello = await store.get('hello')
  
  return new Response(hello)
}

addEventListener("fetch", event => {
  event.respondWith(app(event))
})

0.5.3 (2022-09-16)

Security

• CVE-2022-39218: Fixed Math.random and crypto.getRandomValues methods to always use sufficiently random values. The previous versions would use a PRNG (pseudorandom number generator) which we would seed with a random value however due to our use of Wizer, the initial value to seed the PRNG was baked-in to the final WebAssembly module meaning the sequence of numbers generated was predictable for that specific WebAssembly module. The new implementations of both Math.random and crypto.getRandomValues do not use a PRNG and instead pull random values from WASI (WebAssembly System Interface) libc’s random_get function, which is always a sufficiently random value.

  An attacker with access to the same WebAssembly module that calls the affected methods could use the fixed seed to predict random numbers generated by these functions. This information could be used to bypass cryptographic security controls, for example to disclose sensitive data encrypted by functions that use these generators.

  Developers should update affected modules after applying this patch. Any secrets generated using affected versions should be rotated. Any sensitive ciphertext generated using affected versions should be considered unsafe, e.g. and be deleted or re-generated.

Fixed

• Updated the Typescript definitions for the console methods to indicate that they now accept any number of objects. (#258)

• Store the Object-Store key string into a native object to avoid it becoming garbage collected before being used within ObjectStore.prototype.get or ObjectStore.prototype.put ((381242)

0.5.2 (2022-09-02)

Fixed

• Explicitly declare void as the return type for functions which return nothing - this allows our package to work with typescript's strict:true option (#253)

• Declare ambient types for our npm package instead of exports as we do not yet export anything from the package (#252)