Accessing Token ServerSide w/o Validation #145

Rykuno · 2021-04-18T20:32:10Z

Rykuno
Apr 18, 2021

Here is my current situation.

When making request to my API(Hasura/GQL), I do not always require validation to take part server side as Hasura handles it anyhow via Firebase's JWK Url denoted using the pattern here

As I understand, currently to access the token server side within the app you both export the component with withAuthUser and wrap your getServerSideProps with withAuthUserTokenSSR with performs its own validation of the token such as

export const getServerSideProps = withAuthUserTokenSSR()();
export default withAuthUser({})(MyComponent);

I'm running into two issues

I'm currently required to wrap each component with withAuthUserTokenSSR()() when my only requirement is to access the token for input in an authorization header.
Since validation is done via the JWK URL, its not required within withAuthUserTokenSSR.

I'm pretty new to nextJS and the whole SSR/SSG concepts so I might have an anti-pattern going on, but I'd love input anyhow as I can see myself utilizing this library over and over.

kmjennison · 2021-04-18T22:15:45Z

kmjennison
Apr 18, 2021
Maintainer

I have a few questions about what you're trying to accomplish.

when my only requirement is to access the token for input in an authorization header

Do you need access to the token during SSR or only from the client side? If only client side, you don't need to use withAuthUserTokenSSR.

Since validation is done via the JWK URL, its not required within withAuthUserTokenSSR.

I assume you're using the Firebase ID token. If withAuthUserTokenSSR didn't verify/refresh the ID token, you'd often receive an expired ID token, which I'm guessing you don't want? Or, are you saying your API service already handles token refreshes?

2 replies

Rykuno Apr 18, 2021
Author

Do you need access to the token during SSR or only from the client side? If only client side, you don't need to use withAuthUserTokenSSR.

Both. I currently rely on passing the token from pageProps within _app to make calls utilizing the token server side but of course it's only called when SSR is enabled upon the page with the HOC.

const App = ({ Component, pageProps }: AppProps) => {
  const { AuthUserSerialized } = pageProps;
  const { _token } = AuthUserSerialized ? JSON.parse(AuthUserSerialized) : "";
  const apolloClient = useApollo(pageProps.initialApolloState, _token);

  return (
    <>
      <Head>
        <link rel="shortcut icon" href="/images/favicon.ico" />
      </Head>
      <ApolloProvider client={apolloClient}>
        <ChakraProvider theme={theme}>
          <RootLayout>
            <Component {...pageProps} />
          </RootLayout>
        </ChakraProvider>
      </ApolloProvider>
    </>
  );
};

export default App;

The ApolloClient looks similar to NextJS's example.

I'm sure there is a better way to ingest the token client/server side than the method I'm currently using though.

I assume you're using the Firebase ID token. If withAuthUserTokenSSR didn't verify/refresh the ID token, you'd often receive an expired ID token, which I'm guessing you don't want? Or, are you saying your API service already handles token refreshes?

Ah dang, I completely overlooked that it handled refreshes in this manner. My API used to handle refreshes if receiving an expired token but I since removed it when implementing this library, which of course is exponentially better than how I handled it. I rescind this query in that case.

kmjennison Apr 23, 2021
Maintainer

Just a heads up, the AuthUserSerialized prop and its _token property aren't a documented part of the API, so those might break in the future.

My recommendation is to wrap each page, or create a shared wrapper/layout component if that works for your use case. See #64

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Accessing Token ServerSide w/o Validation #145

{{title}}

Replies: 1 comment 2 replies

{{title}}

{{title}}

{{title}}

Select a reply

Accessing Token ServerSide w/o Validation #145

Rykuno Apr 18, 2021

Replies: 1 comment · 2 replies

kmjennison Apr 18, 2021 Maintainer

Rykuno Apr 18, 2021 Author

kmjennison Apr 23, 2021 Maintainer

Rykuno
Apr 18, 2021

Replies: 1 comment 2 replies

kmjennison
Apr 18, 2021
Maintainer

Rykuno Apr 18, 2021
Author

kmjennison Apr 23, 2021
Maintainer