fix: authMiddleware swallows other headers

[russell-dot-js]

RedwoodApolloProvider allows specifying a graphQLClientConfig. One of these options allows adding links to those provided with redwood via a function, e.g.

link: (rwLinks) => ApolloLink.from([myAwesomeLinkWithACustomHeader, ...rwLinks])

The problem is that the "AuthMiddleware" provided by redwood does not forward any other non-auth related headers, so your only option to add headers are static headers that can be defined via httpLinkConfig.

The temporary workaround is:

link: (rwLinks) => {
  // this will break if redwood changes the order of their links!
  // their "authMiddleware" link is broken and removes all headers
  // that they don't supply. so we want to make sure to insert after
  // them, currently in index 1
  const firstTwo = rwLinks.slice(0, 2);
  const rest = rwLinks.slice(2);

  return ApolloLink.from([...firstTwo, myAwesomeLinkWithACustomHeader, ...rest])
},

Since "AuthMiddleware" is not exported nor does it have any static properties that can be used to determine which link it is, knowledge of the ordering of redwood's internal links array needs to be baked into our custom apollo config.

Gross

[replay-io]

19 replays were recorded for 1c1d9fc.

0 Failed

19 Passed

• requireAuth graphql checks
• useAuth hook, auth redirects checks

  locator.waitFor: Target closed
  =========================== logs ===========================
  waiting for locator('text=Username `testuser@bazinga.com` already in use') to be visible
  ============================================================

• Check that a specific blog post is prerendered
• Check that about is prerendered
• Check that homepage is prerendered
• Check that meta-tags are rendering the correct dynamic data
• Check that rehydration works for page not wrapped in Set
• Check that rehydration works for page with Cell in Set
• Check that rehydration works for page with code split chunks
• Check that you can navigate from home page to specific blog post
• Waterfall prerendering (nested cells)
• RBAC: Admin user should be able to delete contacts
• RBAC: Should not be able to delete contact as non-admin user

  locator.waitFor: Target closed
  =========================== logs ===========================
  waiting for locator('text=Username `admin@bazinga.com` already in use') to be visible
  ============================================================

• Smoke test with dev server
• Smoke test with rw serve
• Loads Cell mocks when Cell is nested in another story
• Loads Cell Stories
• Loads MDX Stories
• Mocks current user, and updates UI while dev server is running

View test run on Replay ↗︎

[jtoar]

Thanks @russell-dot-js; we'll get this fix out, and we realize the API for configuring the link could be easier to work with. If you have a suggestion we're happy to consider it

[russell-dot-js]

Thanks @russell-dot-js; we'll get this fix out, and we realize the API for configuring the link could be easier to work with. If you have a suggestion we're happy to consider it

Thanks for the fast merge @jtoar!
Here are a couple ways to make it easy to configure the link:

1. Export the links

// packages/web/src/apollo/index.tsx

// before
//  const authMiddleware = new ApolloLink((operation, forward) => {

// after
export const authMiddleware = new ApolloLink((operation, forward) => {

// in my redwood app:

link: (rwLinks) => ApolloLink.from(rwLinks.filter(link => link !== authMiddleware))

2. Add a static property to the links so they can be introspected

// packages/web/src/apollo/index.tsx

const authMiddleware = new ApolloLink((operation, forward) => {
  // impl
});

// add this (typescript won't be happy)
authMiddleware.__rw_link_name = 'authMiddleware'

// in my redwood app:

link: (rwLinks) => ApolloLink.from(rwLinks.filter(link => link.__rw_link_name !== 'authMiddleware'))

Second one is gross IMO, first one is simple. Happy to PR whichever you're interested in

[jtoar]

@russell-dot-js exporting the links sounds reasonable. Actually I kind of remember talking about this API at least a year ago, and I think there was a gotcha with exporting some of them because some of them use React Context (specifically the authMiddleware link and the httpLink link depend on the FetchConfigProvider). Maybe it could still be done, but they wouldn't be initialized till the RedwoodApolloProvider renders. Do I have the details there right, and is there still a cocnern there if so?

Another idea: instead of passing an array to the link function, we could pass an object so you can grab the links by name. I think we went with an array so that they'd be in the right order already. But we could provide that information via documentation.

Lastly @russell-dot-js, I just released this fix in v5.2.4.

[russell-dot-js]

@russell-dot-js exporting the links sounds reasonable. Actually I kind of remember talking about this API at least a year ago, and I think there was a gotcha with exporting some of them because some of them use React Context (specifically the authMiddleware link and the httpLink link depend on the FetchConfigProvider). Maybe it could still be done, but they wouldn't be initialized till the RedwoodApolloProvider renders. Do I have the details there right, and is there still a cocnern there if so?

Another idea: instead of passing an array to the link function, we could pass an object so you can grab the links by name. I think we went with an array so that they'd be in the right order already. But we could provide that information via documentation.

Lastly @russell-dot-js, I just released this fix in v5.2.4.

Thanks @jtoar! I'll check out your concerns and see if exporting the links is a nonstarter.