Skip to content
This repository has been archived by the owner on Sep 20, 2023. It is now read-only.

Update dependency apollo-server to v2.25.3 [SECURITY] #4505

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

renovate[bot]
Copy link
Contributor

@renovate renovate bot commented Sep 23, 2020

WhiteSource Renovate

This PR contains the following updates:

Package Change Age Adoption Passing Confidence
apollo-server 2.12.0 -> 2.25.3 age adoption passing confidence

GitHub Vulnerability Alerts

GHSA-w42g-7vfc-xf37

We encourage all users of Apollo Server to read this advisory in its entirety to understand the impact. The Resolution section contains details on patched versions.

Impact

If subscriptions: false is passed to the ApolloServer constructor options, there is no impact. If implementors were not expecting validation rules to be enforced on the WebSocket subscriptions transport and are unconcerned about introspection being enabled on the WebSocket subscriptions transport (or were not expecting that), then this advisory is not applicable. If introspection: true is passed to the ApolloServer constructor options, the impact is limited to user-provided validation rules (i.e., using validationRules) since there would be no expectation that introspection was disabled.

The enforcement of user-provided validation rules on the HTTP transport is working as intended and is unaffected by this advisory. Similarly, disabling introspection on the HTTP transport is working as intended and is unaffected by this advisory.

Note: Unless subscriptions: false is explicitly passed to the constructor parameters of new ApolloServer({ ... }), subscriptions are enabled by default, whether or not there is a Subscription type present in the schema. As an alternative to upgrading to a patched version, see the Workarounds section below to disable subscriptions if it is not necessary.

In cases where subscriptions: false is not explicitly set, the subscription server is impacted since validation rules which are enforced on the main request pipeline within Apollo Server were not being passed to the SubscriptionServer.create invocation (seen here, prior to the patch).

The omitted validation rules for the subscription server include any validationRules passed by implementors to the ApolloServer constructor which were expected to be enforced on the subscriptions WebSocket endpoint. Additionally, because an internal NoIntrospection validation rule is used to disable introspection, it would have been possible to introspect a server on the WebSocket endpoint that the SubscriptionServer creates even though it was not possible on other transports (e.g. HTTP).

The severity of risk depends on whether sensitive information is being stored in the schema itself. The contents of schema descriptions, or secrets which might be revealed by the names of types or field names within those types, will determine the risk to individual implementors.

Affected packages

The bug existed in apollo-server-core versions prior to version 2.14.2, however, this means all integration packages (e.g., apollo-server-express, etc.) prior to version 2.14.2 which depend on apollo-server-core for their subscriptions support are affected. This includes the apollo-server package that automatically provides an Express server.

Therefore, for officially published Apollo Server packages, the full list of affected packages includes: apollo-server, apollo-server-azure-functions, apollo-server-cache-memcached, apollo-server-core, apollo-server-cloud-functions, apollo-server-cloudflare, apollo-server-express, apollo-server-fastify, apollo-server-hapi, apollo-server-koa, apollo-server-lambda, and apollo-server-micro.

Note: The full list included here doesn't fit into the box provided by the GitHub Security Advisories form.

Resolution

The problem is resolved in Apollo Server versions 2.14.2 or higher. If upgrading is not an option, see Workarounds below. When upgrading, ensure that the affected integration package (e.g., apollo-server-express) and the apollo-server-core package are both updated to the patched versions. (The version numbers should both be 2.14.2.)

Workarounds

Upgrading to a patched version is the recommended solution. If upgrading is not an option, subscriptions can be disabled with subscriptions: false to resolve the impact. Disabling subscriptions in this way will disable all subscriptions support and the WebSocket transport:

const server = new ApolloServer({
  subscriptions: false,
  /* Other options, such as typeDefs, resolvers, schema, etc. */
});

For more information

If you have any questions or comments about this advisory, please open an issue and the maintainers will try to assist.

Credit and appreciation

Apollo fully believes in ethical disclosure of vulnerabilities by security researchers who notify us with details and provide us time to address and fix the issues before publicly disclosing.

Credit for this discovery goes to the team at Bitwala, who reported the concern to us responsibly after discovering it during their own auditing.

GHSA-qm7x-rc44-rrqw

Impact

In certain configurations, Apollo Server serves the client-side web app "GraphQL Playground" from the same web server that executes GraphQL operations. This web app has access to cookies and other credentials associated with the web server's operations. There is a cross-site scripting vulnerability in GraphQL Playground that allows for arbitrary JavaScript code execution in your web server's origin. If a user clicks a specially crafted link to your GraphQL Playground page served by Apollo Server, an attacker can steal cookies and other private browser data.

Details of the underlying GraphQL Playground vulnerability are available in this graphql-playground advisory. (A similar vulnerability exists in the related graphiql project.) This advisory focuses on identifying whether Apollo Server installations are vulnerable and mitigating the vulnerability in Apollo Server; see the other advisories for details on the XSS vulnerability itself.

The impact of this vulnerability is more severe if (as is common) your GraphQL server's origin URL is an origin that is used to store sensitive data such as cookies.

In order for this vulnerability to affect your Apollo Server installation, it must actually serve GraphQL Playground. The integration between Apollo Server and GraphQL Playground is different in Apollo Server 2 and Apollo Server 3. You can tell which version of Apollo Server you are running by looking at the version of the package from which you import the ApolloServer class: this may be apollo-server, apollo-server-express, apollo-server-lambda, etc.

Apollo Server 3

Apollo Server 3 does not serve GraphQL Playground by default. It has a landing page plugin system and the default plugin is a simple splash page that is not vulnerable to this exploit, linking to Apollo Sandbox Explorer. (We chose to change the default because GraphQL Playground is not actively maintained.)

If you are running Apollo Server 3, then you are only vulnerable if you explicitly import the ApolloServerPluginLandingPageGraphQLPlayground plugin and pass it to your ApolloServer's constructor in the plugins array. Otherwise, this advisory does not apply to your server.

Apollo Server 2

Apollo Server 2 serves GraphQL Playground by default, unless the NODE_ENV environment variable is set to production, or if you explicitly configure it via the playground option to the ApolloServer constructor.

Your Apollo Server 2 installation is vulnerable if any of the following is true:

  • You pass playground: true to the ApolloServer constructor
  • You pass some other object like playground: {title: "Title"} to the ApolloServer constructor
  • You do not pass any playground option to the ApolloServer constructor, and the NODE_ENV environment variable is not set to production

Apollo Server 1

Apollo Server 1 included graphiql instead of graphql-playground. graphiql isn't automatically enabled in Apollo Server 1: you have to explicitly call a function such as graphiqlExpress to enable it. Because Apollo Server 1 is not commonly used, we have not done a detailed examination of whether the integration between Apollo Server 1 and graphiql is vulnerable to a similar exploit. If you are still using Apollo Server 1, we recommend you disable graphiql by removing the graphiqlExpress call, and then upgrade to a newer version of Apollo Server.

Patches and workarounds

There are several approaches you can take to ensure that your server is not vulnerable to this issue.

Upgrade Apollo Server

The vulnerability has been patched in Apollo Server 2.25.3 and Apollo Server 3.4.1. To get the patch, upgrade your Apollo Server entry point package to one of the fixed versions; this package may be apollo-server, apollo-server-express, apollo-server-lambda, etc. Additionally, if you depend directly on apollo-server-core in your package.json, make sure that you upgrade it to the same version.

Upgrade Playground version only

If upgrading to the latest version of Apollo Server 2 or 3 quickly will be challenging, you can configure your current version of Apollo Server to serve the latest version of the GraphQL Playground app. This will pin your app to serve a specific version of GraphQL Playground and you will not receive updates to it when you upgrade Apollo Server later, but this may be acceptable because GraphQL Playground is not actively maintained.

The way to do this depends on what version of Apollo Server you're using and if you're already configuring GraphQL Playground.

  • Apollo Server 3: If you are using Apollo Server 3, then you are only vulnerable if your serve explicitly calls ApolloServerPluginLandingPageGraphQLPlayground and passes it to the Apollo Server constructor in the plugins array. Add the option version: '1.7.42' to this call, so it looks like:
plugins: [ApolloServerPluginLandingPageGraphQLPlayground({version: '1.7.42'})]
  • Apollo Server 2 with no explicit playground option: If you are using Apollo Server 2 and do not currently pass the playground option to new ApolloServer, add a playground option like so:
new ApolloServer({ playground: process.env.NODE_ENV === 'production' ? false : { version: '1.7.42' } })
  • Apollo Server 2 with playground: true or playground: {x, y, z}: If you are using Apollo Server 2 and currently pass true or an object to new ApolloServer, pass the version option under the playground option like so:
new ApolloServer({ playground: { version: '1.7.42', x, y, z } })

Disable GraphQL Playground

If upgrading Apollo Server or GraphQL Playground is challenging, you can also disable GraphQL Playground.

In Apollo Server 3, remove the call to ApolloServerPluginLandingPageGraphQLPlayground from your ApolloServer constructor's plugins array. This will replace GraphQL Playground with a simple splash page. See the landing page plugins docs for details.

In Apollo Server 2, add playground: false to your ApolloServer constructor: new ApolloServer({ playground: false }). This will replace GraphQL Playground with an attempt to execute a GraphQL operation, which will likely display an error in the browser.

If you disable GraphQL Playground, any users who rely on it to execute GraphQL operations will need an alternative, such as the Apollo Studio Explorer's account-free Sandbox.

Credit

This vulnerability was discovered by @​Ry0taK. Thank you!

The fix to GraphQL Playground was developed by @​acao and @​glasser with help from @​imolorhe, @​divyenduz, and @​benjie.

For more information

If you have any questions or comments about this advisory:


Release Notes

apollographql/apollo-server

v2.25.3

Compare Source

  • ⚠️ SECURITY apollo-server-core: Update default version of the GraphQL Playground React app loaded from the CDN to be @apollographql/graphql-playground-react@1.7.42. This patches an XSS vulnerability. Note that if you are pinning the Playground React app version in your app with new ApolloServer({playground: {version: 'some version'}}), you will need to update the specified version to 1.7.42 or later to avoid this vulnerability. If you disable GraphQL Playground with new ApolloServer({playground: false}), this vulnerability does not affect you. See advisory GHSA-qm7x-rc44-rrqw for more details.

v2.25.2

Compare Source

  • apollo-server-express: Update dependencies on @types/express and @types/express-serve-static-core. PR #​5352

v2.25.1

Compare Source

  • apollo-server-core, apollo-server-express: Upgrade subscriptions-transport-ws dependency and remove unneeded runtime dependency on ws. This should enable you to install Apollo Server without depending on versions of ws vulnerable to CVE-2021-32640. Note that the superficial integration of the unmaintained subscriptions-transport-ws package will be removed in Apollo Server 3; you can also avoid this vulnerability by disabling the built-in subscription support with new ApolloServer({subscriptions: false}) and using a maintained package such as graphql-ws instead. (Instead of taking this upgrade, you can also upgrade ws to 5.2.3, which was just released.)

v2.25.0

Compare Source

  • apollo-server-core: You may now specify your Studio graph as a graph ref (id@variant) via the APOLLO_GRAPH_REF environment variable or new ApolloServer({apollo: {graphRef}}) instead of specifying graph ID and graph variant separately. The apollo object passed to plugin serverWillStart and to gateway load now contains a graphRef field.
  • apollo-server-core: Fix a race condition where schema reporting could lead to a delay at process shutdown. PR #​5222
  • apollo-server-core: Allow the Fetch API implementation to be overridden for the schema reporting and usage reporting plugins via a new fetcher option. PR #​5179
  • apollo-server-core: The server.executeOperation method (designed for testing) can now take its query as a DocumentNode (eg, a gql-tagged string) in addition to as a string. (This matches the behavior of the apollo-server-testing createTestClient function which is now deprecated.) We now recommend this method instead of apollo-server-testing in our docs. Issue #​4952
  • apollo-server-testing: Replace README with a deprecation notice explaining how to use server.executeOperation instead. Issue #​4952

v2.24.1

Compare Source

  • apollo-server-core: Fix a typo that could lead to TypeScript compilation when combined with a recent version of @types/node. (This bug had no runtime effect.) PR #​5149

v2.24.0

Compare Source

  • apollo-server-core: Apollo Studio usage reporting uses a more efficient format which sends fewer detailed traces to Apollo's server. This change should not have a major effect on the experience of using Apollo Studio. This also fixes a bug in all prior versions where all operations were reported to Studio as "uncached". PR #​4142

v2.23.0

Compare Source

  • apollo-server-core: Add optional argument to ApolloServer.executeOperation allowing the caller to manually specify an argument to the config function analogous to that provided by integration packages. PR #​4166 Issue #​2886
  • apollo-server-cache-redis@1.4.0: New BaseRedisCache class which takes an ioredis-compatible Redis client as an argument. The existing classes RedisCache and RedisClusterCache (which pass their arguments to ioredis constructors) are now implemented in terms of this class. This allows you to use any of the ioredis constructor forms rather than just the ones recognized by our classes. This also fixes a long-standing bug where the Redis cache implementations returned a number from delete(); it now returns a number, matching what the KeyValueCache interface and the TypeScript types expect. PR #​5034 PR #​5088 Issue #​4870 Issue #​5006
  • apollo-server-core: Fix type for formatResponse function. It never is called with a null argument, and is allowed to return null. Issue #​5009 PR #​5089
  • apollo-server-lambda: Fix regression in v2.21.2 where thrown errors were replaced by throwing the JS Error class itself. PR #​5085
  • apollo-server-core: If a client sends a variable of the wrong type, this is now reported as an error with an extensions.code of BAD_USER_INPUT rather than INTERNAL_SERVER_ERROR. PR #​5091 Issue #​3498
  • apollo-server-lambda: Explicitly support API Gateway payloadFormatVersion 2.0. Previously some codepaths did appropriate checks to partially support 2.0 and other codepaths could lead to errors like event.path.endsWith is not a function (especially since v2.21.1). Note that this changes the TypeScript typing of the onHealthCheck callback passed to createHandler to indicate that it can receive either type of event. If you are using TypeScript and care about having a precise typing for the argument to your onHealthCheck callback, you should determine which payload format you want to support and write new ApolloServer<APIGatewayProxyEvent>(...) or new ApolloServer<APIGatewayProxyEventV2>(...) (importing these types from aws-lambda), or differentiate between the two formats by checking to see if 'path' in event. Issue #​5084 Issue #​5016

v2.22.2

Compare Source

  • apollo-server-core: Fix a regression in v2.22.0 where combining apollo-server-core v2.22 with an older version of an integration package could lead to startup errors like called start() with surprising state invoking serverWillStart. The fix involves changing the semantics of the protected willStart method (which is left in only for backwards compatibility). Issue #​5065 Issue #​5066 PR #​5073

v2.22.1

Compare Source

  • apollo-server-core: Fix a regression in v2.22.0 where startup errors could be thrown as part of the GraphQL response instead of redacted in one edge case. PR #​5064

v2.22.0

Compare Source

  • Improve startup error handling by ensuring that your server has loaded its schema and executed its serverWillStart handlers successfully before starting an HTTP server. If you're using the apollo-server package, no code changes are necessary. If you're using an integration such as apollo-server-express that is not a "serverless framework", you can insert await server.start() between server = new ApolloServer() and server.applyMiddleware. (If you don't call server.start() yourself, your server will still work, but the previous behavior of starting a web server that may fail to load its schema still applies.) The serverless framework integrations (Lambda, Azure Functions, and Cloud Functions) do not support this functionality. While the protected method willStart still exists for backwards compatibility, you should replace calls to it with start or the new protected method ensureStarting. PR #​4981

v2.21.2

Compare Source

  • apollo-server-core: The SIGINT and SIGTERM signal handlers installed by default (when not disabled by stopOnTerminationSignals: false) now stay active (preventing process termination) while the server shuts down, instead of letting a second signal terminate the process. The handlers still re-signal the process after this.stop() concludes. Also, if this.stop() throws, the signal handlers will now log and exit 1 instead of throwing an uncaught exception. Issue #​4931
  • apollo-server-lambda: Refactor the handler returned by server.createHandler so that if it is not passed a callback, it acts as an async handler instead of a non-async handler. This means you can wrap it in your own async handler without having to create a callback, and makes the code more maintainable. Issue #​1989 PR #​5004

v2.21.1

Compare Source

  • apollo-server-lambda: The onHealthCheck option did not previously work. Additionally, health checks (with onHealthCheck or without) didn't work in all Lambda contexts, such as behind Custom Domains; the path check is now more flexible. Issue #​3999 PR #​4969 Issue #​4891 PR #​4892
  • The debug option to new ApolloServer (which adds stack traces to errors) now affects errors that come from requests executed with server.executeOperation (and its wrapper apollo-server-testing), instead of just errors that come from requests executed over HTTP. Issue #​4107 PR #​4948
  • Bump version of @apollographql/graphql-playground-html to v1.6.27 and @apollographql/graphql-playground-react to v1.7.39 to resolve incorrectly rendered CDN URL when Playground version was false-y. PR #​4932 PR #​4955 Issue #​4937

v2.21.0

Compare Source

  • Apollo Server can now be installed with graphql@15 without causing peer dependency errors or warnings. (Apollo Server has a file upload feature which was implemented as a wrapper around the graphql-upload package. We have been unable to upgrade our dependency on that package due to backwards-incompatible changes in later versions, and the version we were stuck on did not allow graphql@15 as a peer dependency. We have now switched to a fork of that old version called @apollographql/graphql-upload-8-fork that allows graphql@15.) Also bump the graphql-tools dependency from 4.0.0 to 4.0.8 for graphql@15 support. Issue #​4865

v2.20.0

Compare Source

  • apollo-server: Previously, ApolloServer.stop() functioned like net.Server.close() in that it did not close idle connections or close active connections after a grace period. This meant that trying to await ApolloServer.stop() could hang indefinitely if there are open connections. Now, this method closes idle connections, and closes active connections after 10 seconds. The grace period can be adjusted by passing the new stopGracePeriodMillis option to new ApolloServer, or disabled by passing Infinity (though it will still close idle connections). Note that this only applies to the "batteries-included" ApolloServer in the apollo-server package with its own built-in Express and HTTP servers. PR #​4908 Issue #​4097
  • apollo-server-core: When used with ApolloGateway, ApolloServer.stop now invokes ApolloGateway.stop. (This makes sense because ApolloServer already invokes ApolloGateway.load which is what starts the behavior stopped by ApolloGateway.stop.) Note that @apollo/gateway 0.23 will expect to be stopped in order for natural program shutdown to occur. PR #​4907 Issue #​4428
  • apollo-server-core: Avoid instrumenting schemas for the old graphql-extensions library unless extensions are provided. PR #​4893 Issue #​4889
  • apollo-server-plugin-response-cache@0.6.0: The shouldReadFromCache and shouldWriteToCache hooks were always documented as returning ValueOrPromise<boolean> (ie, that they could be either sync or async), but they actually only worked if they returned a bool. Now they can be either sync or async as intended. PR #​4890 Issue #​4886
  • apollo-datasource-rest@0.10.0: The RESTDataSource.trace method is now protected instead of private to allow more control over logging and metrics. PR #​3940

v2.19.2

Compare Source

  • apollo-server-express: types: Export ExpressContext from main module. PR #​4821 Issue #​3699
  • apollo-server-env: types: The first parameter to fetch is now marked as required, as intended and in accordance with the Fetch API specification. PR #​4822 Issue #​4741
  • apollo-server-core: Update graphql-tag package to latest, now with its graphql-js peerDependencies expanded to include ^15.0.0 PR #​4833

v2.19.1

Compare Source

  • apollo-server-core: The debugPrintReports option to ApolloServerPluginUsageReporting now prints traces as well. PR #​4805

v2.19.0

Compare Source

  • apollo-server-testing: types: Allow generic variables usage of query and mutate functions. PR #​4383
  • apollo-server-express: Export the GetMiddlewareOptions type. PR #​4599
  • apollo-server-lambda: Fix file uploads - ignore base64 decoding for multipart queries. PR #​4506
  • apollo-server-core: Do not send operation documents that cannot be executed to Apollo Studio. Instead, information about these operations will be combined into one "operation" for parse failures, one for validation failures, and one for unknown operation names.

v2.18.2

Compare Source

  • apollo-server-core: Explicitly include lru-cache dependency in apollo-server-core's dependencies. PR #​4600

v2.18.1

Compare Source

  • apollo-server-core: Fix support for legacy option engine: {logger}, broken in v2.18.0. PR #​4588

  • apollo-server-plugin-base: The ApolloServerPlugin TypeScript type does not need to extend AnyFunctionMap, which was an unnecessary change in v2.18.0. PR #​4588

  • apollo-server-core: Improve a usage reporting error which occurs when you use Apollo Server in an unsupported way. PR #​4588

  • apollo-server-core: Fix typo in error message for unparsable/invalid schemas provided via overrideReportedSchema. PR #​4581

v2.18.0

Compare Source

  • apollo-server-core: When Apollo Server is configured with an Apollo API key, the URLs it uses to connect to Apollo's servers have changed. If the environment in which you run your servers requires you to explicitly allow connections by domain, you will need to add the new domain names. Usage reporting previously connected to https://engine-report.apollodata.com/ and now connects to https://usage-reporting.api.apollographql.com/; schema reporting previously connected to https://edge-server-reporting.api.apollographql.com/ and now connects to https://schema-reporting.api.apollographql.com/ . PR #​4453

  • Apollo Server's support for communicating with Apollo’s commercial products has been refactored into three separate plugins exported from apollo-server-core (for usage reporting, schema reporting, and inline tracing), configured using the standard plugins option. The engine option continues to work for backwards compatibility in the 2.x series; support for engine will be deprecated in Apollo Server 3.x. Full details are available in the migration guide. PR #​4453

  • To consistently support tracing, inline tracing is enabled by default on federated implementing services, even when an Apollo API key is provided. Previously it was not enabled when an API key was provided. You can disable it with ApolloServerPluginInlineTraceDisabled. PR #​4453

  • The apollo-engine-reporting npm package has been obsoleted and will no longer receive updates. PR #​4453

  • The apollo-engine-reporting-protobuf package has been renamed to apollo-reporting-protobuf. No new versions of the old package will be published. PR #​4453

  • Implementations of ApolloServer for serverless frameworks such as Lambda now override the serverlessFramework() method to return true. We have changed our own integrations, but other implementations that extend ApolloServer which need this behavior should do the same. Support for engine.sendReportsImmediately will be dropped in Apollo Server 3.x. PR #​4453

  • The GraphQLServiceContext type passed to the plugin serverWillStart method now contains apollo and serverlessFramework values. PR #​4453

  • apollo-server-core / apollo-server-plugin-base: The request pipeline plugin API now supports a serverWillStop lifecycle hook. PR #​4453

  • apollo-server-core: Previously, the usage reporting functionality registered one-shot handlers for the SIGINT and SIGTERM signals, which it used to send one final usage report before re-sending the signal to itself to continue shutdown. These signals handlers were installed by default if you enabled usage or schema reporting, and could be disabled by passing engine.handleSignals: false. Now, termination signal handling is the responsibility of Apollo Server as a whole rather than something specific to usage reporting. Apollo Server itself now registers these one-shot signal handlers, which trigger ApolloServer.stop(). This allows any plugin that implements the new serverWillStop callback to hook into shutdown logic, not just the usage reporting code. Similarly to before, these signal handlers are registered by default but can be disabled by via an option. We've changed the option name to stopOnTerminationSignals: false as it is more explicit about the behavior. PR #​4453

  • apollo-server-core: The default logger implementation (if you don't specify your own logger or specify debug) now logs at the INFO level instead of the WARN level. The main effect is on a few built-in plugins which log one INFO message at startup; if a custom plugin logs at the INFO level then those messages will be visible by default as well. PR #​4453

  • apollo-server-core: Parse and validate any schema passed via overrideReportedSchema to the schema reporting plugin, and throw accordingly on unparsable or invalid schemas.

  • Using Apollo Server from TypeScript now requires TypeScript 3.8 due to the use of the import type and export type directives. (If this proves to be a major problem we can revert this choice, but it makes it easier for us to ensure that certain large dependencies are only loaded when needed.) PR #​4453

  • Updated @apollographql/graphql-playground-react to 1.7.33 to include an upstream fix. PR #​4550

v2.17.0

Compare Source

  • subscriptions: Fix bug which prevented installSubscriptionHandlers from accepting a websocket.Server (as intended in PR #​1966) and also added support for other http.Server variations (e.g., Tls). Issue #​4198 PR #​4200

v2.16.1

Compare Source

  • This release only includes patch updates to dependencies.

v2.16.0

Compare Source

v2.15.1

Compare Source

  • The default branch of the repository has been changed to main. As this changed a number of references in the repository's package.json and README.md files (e.g., for badges, links, etc.), this necessitates a release to publish those changes to npm. PR #​4302

v2.15.0

Compare Source

  • apollo-engine-reporting: Added a reportTiming API to allow trace reporting to be enabled or disabled on a per request basis. The option takes either a boolean or a predicate function that takes a GraphQLRequestContextDidResolveOperation or GraphQLRequestContextDidEncounterErrors and returns a boolean. If the boolean is false the request will not be instrumented for tracing and no trace will be sent to Apollo Graph Manager. The default is true so all traces will get instrumented and sent, which is the same as the previous default behavior. PR #​3918
  • apollo-engine-reporting: Removed GraphQLServerOptions.reporting. It isn't known whether a trace will be reported at the beginning of the request because of the above change. We believe this field was only used internally within Apollo Server; let us know if this is a problem and we can suggest alternatives. Additionally, the field requestContext.metrics.captureTraces is now initialized later in the request pipeline. PR #​3918
  • apollo-engine-reporting: Make Apollo Server throw if schema reporting is enabled for a gateway or federated service. PR #​4246
  • apollo-engine-reporting: Remove the experimental_ prefix from schema reporting options, and specifically rename experimental_schemaReporting option name to reportSchema. (The old option names remain functional, but are deprecated.) PR #​4236

v2.14.5

Compare Source

  • apollo-engine-reporting: Make Apollo Server throw if schema reporting is enabled for a gateway or federated service. PR #​4246

v2.14.4

Compare Source

  • apollo-engine-reporting: Add environment variable APOLLO_SCHEMA_REPORTING that can enable schema reporting. If experimental__schemaReporting is set it will override the environment variable. PR #​4206
  • apollo-engine-reporting: The schema reporting URL has been changed to use the new dedicated sub-domain https://edge-server-reporting.api.apollographql.com. PR #​4232
  • apollo-server-core: Though Apollo Server is not affected due to the way it is integrated, in response to an upstream security advisory for GraphQL Playground we have published the same patch on our @apollographql/graphql-playground-html fork and bumped Apollo Server to use it. Again, this was done out of an abundance of caution since the way that Apollo Server utilizes renderPlaygroundPage is not vulnerable as it does not allow per-request Playground configuration that could allow interpolation of user-input. PR #​4231

v2.14.3

Compare Source

  • This release only includes patch updates to dependencies.

v2.14.2

Compare Source

Note: This release is is related to a GitHub Security Advisory published by the Apollo Server team. Please read the attached advisory to understand the impact.

v2.14.1

Compare Source

See complete versioning details.

v2.14.0

Compare Source

See complete versioning details.

  • apollo-server-core / apollo-server-plugin-base: Add support for willResolveField and corresponding end-handler within executionDidStart. This brings the remaining bit of functionality that was previously only available from graphql-extensions to the new plugin API. The graphql-extensions API (which was never documented) will be deprecated in Apollo Server 3.x. To see the documentation for the request pipeline API, see its documentation. For more details, see the attached PR. PR #​3988

  • apollo-server-core: Deprecate graphql-extensions. All internal usages of the graphql-extensions API have been migrated to the request pipeline plugin API. For any implementor-supplied extensions, a deprecation warning will be printed once per-extension, per-server-startup, notifying of the intention to deprecate. Extensions should migrate to the plugin API, which is outlined in its documentation. PR #​4135

  • apollo-engine-reporting: Currently only for non-federated graphs.
    Added an experimental schema reporting option,
    experimental_schemaReporting, for Apollo Graph Manager users. During
    this experiment, we'd appreciate testing and feedback from current and new
    users of the schema registry!

    Prior to the introduction of this feature, the only way to get schemas into
    the schema registry in Apollo Graph Manager was to use the CLI and run
    apollo schema:push. Apollo schema reporting protocol is a new
    specification for GraphQL servers to automatically report schemas to the
    Apollo Graph Manager schema registry.

    To enable schema reporting, provide a Graph Manager API key (available
    free from Apollo Graph Manager) in the
    APOLLO_KEY environment variable and set the experimental_schemaReporting
    option to true in the Apollo Server constructor options, like so:

    const server = new ApolloServer({
      typeDefs,
      resolvers,
      engine: {
        experimental_schemaReporting: true,
        /* Other existing options can remain the same. */
      },
    });

    When enabled, a schema reporter is initiated by the apollo-engine-reporting agent. It will loop until the ApolloServer instance is stopped, periodically calling back to Apollo Graph Manager to send information. The life-cycle of this reporter is managed by the agent.

    For more details on the implementation of this new protocol, see the PR which
    introduced it to Apollo Server and the preview documentation.

    PR #​4084

  • apollo-engine-reporting: The underlying integration of this plugin, which instruments and traces the graph's resolver performance and transmits these metrics to Apollo Graph Manager, has been changed from the (soon to be deprecated) graphql-extensions API to the new request pipeline plugins API. PR #​3998

    This change should be purely an implementation detail for a majority of users. There are, however, some special considerations which are worth noting:

    • The federated tracing plugin's ftv1 response on extensions (which is present on the response from an implementing service to the gateway) is now placed on the extensions after the formatResponse hook. Anyone leveraging the extensions.ftv1 data from the formatResponse hook will find that it is no longer present at that phase.
  • apollo-tracing: This package's internal integration with Apollo Server has been switched from using the soon-to-be-deprecated graphql-extensions API to using the request pipeline plugin API. Behavior should remain otherwise the same. PR #​3991

  • apollo-cache-control: This package's internal integration with Apollo Server has been switched from using the soon-to-be-deprecated graphql-extensions API to using the request pipeline plugin API. Behavior should remain otherwise the same. PR #​3997

v2.13.1

Compare Source

v2.13.0

Compare Source

See complete versioning details.

  • Allow passing a WebSocket.Server to ApolloServer.installSubscriptionHandlers. PR #​2314
  • apollo-server-lambda: Support file uploads on AWS Lambda Issue #​1419 Issue #​1703 PR #​3926
  • apollo-engine-reporting: Fix inadvertent conditional formatting which prevented automated persisted query (APQ) hits and misses from being reported to Apollo Graph Manager. PR #​3986
  • apollo-engine-reporting: Deprecate the ENGINE_API_KEY environment variable in favor of its new name, APOLLO_KEY. Continued use of ENGINE_API_KEY will result in deprecation warnings and support for it will be removed in a future major version. #​3923
  • apollo-engine-reporting: Deprecated the APOLLO_SCHEMA_TAG environment variable in favor of its new name, APOLLO_GRAPH_VARIANT. Similarly, within the engine configuration object, the schemaTag property has been renamed graphVariant. The functionality remains otherwise unchanged, but their new names mirror the name used within Apollo Graph Manager. Continued use of the now-deprecated names will result in deprecation warnings and support will be dropped completely in the next "major" update. To avoid misconfiguration, a runtime error will be thrown if both new and deprecated names are set. PR #​3855
  • apollo-engine-reporting-protobuf: (This is a breaking change only if you directly depend on apollo-engine-reporting-protobuf.) Drop legacy fields that were never used by apollo-engine-reporting. Added new fields StatsContext to allow apollo-server to send summary stats instead of full traces, and renamed FullTracesReport to Report and Traces to TracesAndStats since reports now can include stats as well as traces.

Configuration

📅 Schedule: "" (UTC).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.


  • If you want to rebase/retry this PR, click this checkbox.

This PR has been generated by WhiteSource Renovate. View repository job log here.

@renovate renovate bot force-pushed the renovate/npm-apollo-server-vulnerability branch 30 times, most recently from 5f4778e to dd4b6a2 Compare October 30, 2020 20:33
@renovate renovate bot force-pushed the renovate/npm-apollo-server-vulnerability branch 24 times, most recently from 4eaa39a to 07bbab4 Compare November 4, 2020 14:32
@renovate renovate bot force-pushed the renovate/npm-apollo-server-vulnerability branch from 07bbab4 to fc93317 Compare December 15, 2020 22:27
@renovate renovate bot force-pushed the renovate/npm-apollo-server-vulnerability branch 2 times, most recently from ec9f8db to 8f61a99 Compare February 11, 2021 01:25
@renovate renovate bot force-pushed the renovate/npm-apollo-server-vulnerability branch from 8f61a99 to 3611d9b Compare November 14, 2021 04:10
@renovate renovate bot changed the title Update dependency apollo-server to v2.14.2 [SECURITY] Update dependency apollo-server to v2.25.3 [SECURITY] Nov 14, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant