origin
origin copied to clipboard
Update dependency apollo-server to v2.25.3 [SECURITY]
This PR contains the following updates:
Package | Change | Age | Adoption | Passing | Confidence |
---|---|---|---|---|---|
apollo-server | 2.12.0 -> 2.25.3 |
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 ofnew ApolloServer({ ... })
, subscriptions are enabled by default, whether or not there is aSubscription
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 theApolloServer
constructor - You pass some other object like
playground: {title: "Title"}
to theApolloServer
constructor - You do not pass any
playground
option to theApolloServer
constructor, and theNODE_ENV
environment variable is not set toproduction
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 theplugins
array. Add the optionversion: '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 theplayground
option tonew ApolloServer
, add aplayground
option like so:
new ApolloServer({ playground: process.env.NODE_ENV === 'production' ? false : { version: '1.7.42' } })
-
Apollo Server 2 with
playground: true
orplayground: {x, y, z}
: If you are using Apollo Server 2 and currently passtrue
or an object tonew ApolloServer
, pass theversion
option under theplayground
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:
- Read the
graphql-playground
advisory - Open an issue in the
apollo-server
repo - If the issue involves confidential information, email us at [email protected]
Release Notes
apollographql/apollo-server
v2.25.3
- ⚠️ SECURITY
apollo-server-core
: Update default version of the GraphQL Playground React app loaded from the CDN to be@apollographql/[email protected]
. This patches an XSS vulnerability. Note that if you are pinning the Playground React app version in your app withnew 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 withnew ApolloServer({playground: false})
, this vulnerability does not affect you. See advisory GHSA-qm7x-rc44-rrqw for more details.
v2.25.2
-
apollo-server-express
: Update dependencies on@types/express
and@types/express-serve-static-core
. PR #5352
v2.25.1
-
apollo-server-core
,apollo-server-express
: Upgradesubscriptions-transport-ws
dependency and remove unneeded runtime dependency onws
. This should enable you to install Apollo Server without depending on versions ofws
vulnerable to CVE-2021-32640. Note that the superficial integration of the unmaintainedsubscriptions-transport-ws
package will be removed in Apollo Server 3; you can also avoid this vulnerability by disabling the built-in subscription support withnew ApolloServer({subscriptions: false})
and using a maintained package such asgraphql-ws
instead. (Instead of taking this upgrade, you can also upgradews
to5.2.3
, which was just released.)
v2.25.0
-
apollo-server-core
: You may now specify your Studio graph as a graph ref (id@variant
) via theAPOLLO_GRAPH_REF
environment variable ornew ApolloServer({apollo: {graphRef}})
instead of specifying graph ID and graph variant separately. Theapollo
object passed to pluginserverWillStart
and to gatewayload
now contains agraphRef
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 newfetcher
option. PR #5179 -
apollo-server-core
: Theserver.executeOperation
method (designed for testing) can now take itsquery
as aDocumentNode
(eg, agql
-tagged string) in addition to as a string. (This matches the behavior of theapollo-server-testing
createTestClient
function which is now deprecated.) We now recommend this method instead ofapollo-server-testing
in our docs. Issue #4952 -
apollo-server-testing
: Replace README with a deprecation notice explaining how to useserver.executeOperation
instead. Issue #4952
v2.24.1
-
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
-
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
-
apollo-server-core
: Add optional argument toApolloServer.executeOperation
allowing the caller to manually specify an argument to theconfig
function analogous to that provided by integration packages. PR #4166 Issue #2886 -
[email protected]
: NewBaseRedisCache
class which takes anioredis
-compatible Redis client as an argument. The existing classesRedisCache
andRedisClusterCache
(which pass their arguments toioredis
constructors) are now implemented in terms of this class. This allows you to use any of theioredis
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 fromdelete()
; it now returns a number, matching what theKeyValueCache
interface and the TypeScript types expect. PR #5034 PR #5088 Issue #4870 Issue #5006 -
apollo-server-core
: Fix type forformatResponse
function. It never is called with anull
argument, and is allowed to returnnull
. 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 anextensions.code
ofBAD_USER_INPUT
rather thanINTERNAL_SERVER_ERROR
. PR #5091 Issue #3498 -
apollo-server-lambda
: Explicitly support API GatewaypayloadFormatVersion
2.0. Previously some codepaths did appropriate checks to partially support 2.0 and other codepaths could lead to errors likeevent.path.endsWith is not a function
(especially since v2.21.1). Note that this changes the TypeScript typing of theonHealthCheck
callback passed tocreateHandler
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 youronHealthCheck
callback, you should determine which payload format you want to support and writenew ApolloServer<APIGatewayProxyEvent>(...)
ornew ApolloServer<APIGatewayProxyEventV2>(...)
(importing these types fromaws-lambda
), or differentiate between the two formats by checking to see if'path' in event
. Issue #5084 Issue #5016
v2.22.2
-
apollo-server-core
: Fix a regression in v2.22.0 where combiningapollo-server-core
v2.22 with an older version of an integration package could lead to startup errors likecalled start() with surprising state invoking serverWillStart
. The fix involves changing the semantics of the protectedwillStart
method (which is left in only for backwards compatibility). Issue #5065 Issue #5066 PR #5073
v2.22.1
-
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
- 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 theapollo-server
package, no code changes are necessary. If you're using an integration such asapollo-server-express
that is not a "serverless framework", you can insertawait server.start()
betweenserver = new ApolloServer()
andserver.applyMiddleware
. (If you don't callserver.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 methodwillStart
still exists for backwards compatibility, you should replace calls to it withstart
or the new protected methodensureStarting
. PR #4981
v2.21.2
-
apollo-server-core
: TheSIGINT
andSIGTERM
signal handlers installed by default (when not disabled bystopOnTerminationSignals: 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 afterthis.stop()
concludes. Also, ifthis.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 byserver.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
-
apollo-server-lambda
: TheonHealthCheck
option did not previously work. Additionally, health checks (withonHealthCheck
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 tonew ApolloServer
(which adds stack traces to errors) now affects errors that come from requests executed withserver.executeOperation
(and its wrapperapollo-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 Playgroundversion
wasfalse
-y. PR #4932 PR #4955 Issue #4937
v2.21.0
- 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 thegraphql-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 allowgraphql@15
as a peer dependency. We have now switched to a fork of that old version called@apollographql/graphql-upload-8-fork
that allowsgraphql@15
.) Also bump thegraphql-tools
dependency from 4.0.0 to 4.0.8 forgraphql@15
support. Issue #4865
v2.20.0
-
apollo-server
: Previously,ApolloServer.stop()
functioned likenet.Server.close()
in that it did not close idle connections or close active connections after a grace period. This meant that trying toawait 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 newstopGracePeriodMillis
option tonew ApolloServer
, or disabled by passingInfinity
(though it will still close idle connections). Note that this only applies to the "batteries-included"ApolloServer
in theapollo-server
package with its own built-in Express and HTTP servers. PR #4908 Issue #4097 -
apollo-server-core
: When used withApolloGateway
,ApolloServer.stop
now invokesApolloGateway.stop
. (This makes sense becauseApolloServer
already invokesApolloGateway.load
which is what starts the behavior stopped byApolloGateway.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 oldgraphql-extensions
library unless extensions are provided. PR #4893 Issue #4889 -
[email protected]
: TheshouldReadFromCache
andshouldWriteToCache
hooks were always documented as returningValueOrPromise<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 -
[email protected]
: TheRESTDataSource.trace
method is nowprotected
instead ofprivate
to allow more control over logging and metrics. PR #3940
v2.19.2
-
apollo-server-express
: types: ExportExpressContext
from main module. PR #4821 Issue #3699 -
apollo-server-env
: types: The first parameter tofetch
is now marked as required, as intended and in accordance with the Fetch API specification. PR #4822 Issue #4741 -
apollo-server-core
: Updategraphql-tag
package tolatest
, now with itsgraphql-js
peerDependencies
expanded to include^15.0.0
PR #4833
v2.19.1
-
apollo-server-core
: ThedebugPrintReports
option toApolloServerPluginUsageReporting
now prints traces as well. PR #4805
v2.19.0
-
apollo-server-testing
: types: Allow genericvariables
usage ofquery
andmutate
functions. PR #4383 -
apollo-server-express
: Export theGetMiddlewareOptions
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
-
apollo-server-core
: Explicitly includelru-cache
dependency inapollo-server-core
's dependencies. PR #4600
v2.18.1
-
apollo-server-core
: Fix support for legacy optionengine: {logger}
, broken in v2.18.0. PR #4588 -
apollo-server-plugin-base
: TheApolloServerPlugin
TypeScript type does not need to extendAnyFunctionMap
, 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 viaoverrideReportedSchema
. PR #4581
v2.18.0
-
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 standardplugins
option. Theengine
option continues to work for backwards compatibility in the 2.x series; support forengine
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 toapollo-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 theserverlessFramework()
method to return true. We have changed our own integrations, but other implementations that extendApolloServer
which need this behavior should do the same. Support forengine.sendReportsImmediately
will be dropped in Apollo Server 3.x. PR #4453 -
The
GraphQLServiceContext
type passed to the plugin serverWillStart method now containsapollo
andserverlessFramework
values. PR #4453 -
apollo-server-core
/apollo-server-plugin-base
: The request pipeline plugin API now supports aserverWillStop
lifecycle hook. PR #4453 -
apollo-server-core
: Previously, the usage reporting functionality registered one-shot handlers for theSIGINT
andSIGTERM
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 passingengine.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 triggerApolloServer.stop()
. This allows any plugin that implements the newserverWillStop
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 tostopOnTerminationSignals: false
as it is more explicit about the behavior. PR #4453 -
apollo-server-core
: The default logger implementation (if you don't specify your ownlogger
or specifydebug
) 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 viaoverrideReportedSchema
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
andexport 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
- subscriptions: Fix bug which prevented
installSubscriptionHandlers
from accepting awebsocket.Server
(as intended in PR #1966) and also added support for otherhttp.Server
variations (e.g., Tls). Issue #4198 PR #4200
v2.16.1
- This release only includes patch updates to dependencies.
v2.16.0
-
apollo-server-fastify
: Pass Fastify'srequest
andreply
objects into thecontext
function, which previously had been receiving nothing. Issue #3156 [PR #3895(https://github.com/apollographql/apollo-server/pull/3895) -
apollo-server-lamdbda
: Automatically decode payloads which are Base64-encoded when theisBase64Encoded
boolean is present on Lambdaevent
payloads. PR #4311
v2.15.1
- The default branch of the repository has been changed to
main
. As this changed a number of references in the repository'spackage.json
andREADME.md
files (e.g., for badges, links, etc.), this necessitates a release to publish those changes to npm. PR #4302
v2.15.0
-
apollo-engine-reporting
: Added areportTiming
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 aGraphQLRequestContextDidResolveOperation
orGraphQLRequestContextDidEncounterErrors
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 istrue
so all traces will get instrumented and sent, which is the same as the previous default behavior. PR #3918 -
apollo-engine-reporting
: RemovedGraphQLServerOptions.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 fieldrequestContext.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 theexperimental_
prefix from schema reporting options, and specifically renameexperimental_schemaReporting
option name toreportSchema
. (The old option names remain functional, but are deprecated.) PR #4236
v2.14.5
-
apollo-engine-reporting
: Make Apollo Server throw if schema reporting is enabled for a gateway or federated service. PR #4246
v2.14.4
-
apollo-engine-reporting
: Add environment variableAPOLLO_SCHEMA_REPORTING
that can enable schema reporting. Ifexperimental__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-domainhttps://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 utilizesrenderPlaygroundPage
is not vulnerable as it does not allow per-request Playground configuration that could allow interpolation of user-input. PR #4231
v2.14.3
- This release only includes patch updates to dependencies.
v2.14.2
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.
- ⚠️ SECURITY: Pass all schema validation rules to the subscription server, including validation rules that restrict introspection when introspection is meant to be disabled. Read the full GitHub Security Advisory for details.
v2.14.1
-
apollo-server-testing
: Ensure that user-provided context is cloned when usingcreateTestClient
, per the instructions in the integration testing section of the Apollo Server documentation. Issue #4170 PR #4175
v2.14.0
-
apollo-server-core
/apollo-server-plugin-base
: Add support forwillResolveField
and corresponding end-handler withinexecutionDidStart
. This brings the remaining bit of functionality that was previously only available fromgraphql-extensions
to the new plugin API. Thegraphql-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
: Deprecategraphql-extensions
. All internal usages of thegraphql-extensions
API have been migrated to the request pipeline plugin API. For any implementor-suppliedextensions
, 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 theexperimental_schemaReporting
option totrue
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 theApolloServer
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.
-
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 pipelineplugins
API. PR #3998This 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 onextensions
(which is present on the response from an implementing service to the gateway) is now placed on theextensions
after theformatResponse
hook. Anyone leveraging theextensions
.ftv1
data from theformatResponse
hook will find that it is no longer present at that phase.
- The federated tracing plugin's
-
apollo-tracing
: This package's internal integration with Apollo Server has been switched from using the soon-to-be-deprecatedgraphql-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-deprecatedgraphql-extensions
API to using the request pipeline plugin API. Behavior should remain otherwise the same. PR #3997
v2.13.1
v2.13.0
- Allow passing a
WebSocket.Server
toApolloServer.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 theENGINE_API_KEY
environment variable in favor of its new name,APOLLO_KEY
. Continued use ofENGINE_API_KEY
will result in deprecation warnings and support for it will be removed in a future major version. #3923 -
apollo-engine-reporting
: Deprecated theAPOLLO_SCHEMA_TAG
environment variable in favor of its new name,APOLLO_GRAPH_VARIANT
. Similarly, within theengine
configuration object, theschemaTag
property has been renamedgraphVariant
. 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 onapollo-engine-reporting-protobuf
.) Drop legacy fields that were never used byapollo-engine-reporting
. Added new fieldsStatsContext
to allowapollo-server
to send summary stats instead of full traces, and renamedFullTracesReport
toReport
andTraces
toTracesAndStats
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.