amplify-js: Next.js and AWS Amplify - `custom_header` defined in Amplify.configure() doesn't work with SSR Calls (REST, not GraphQL)

@phstc I was finally able to get passed the "No current user" error.

It seems like the custom header in your amplify configure might be causing the issue. I did quite a bit of digging and logging and noticed that the error was actually being thrown from AuthClass and the more specific error was "Failed to get user from user pool"

I was able to get rid of the error by removing the entire custom_header section from Amplify.configure.

Personally, I am now getting 401/403 errors but I believe that is a different issue from how I set up this API.

Please let me know if this solves the issue for you as well

EDIT: Another note, it works successfully when I manually configure the project with the resources that I made through the CLI, so my 401/403 errors were definitely from some bad resource setup on my end.

My final configuration was as follows:

Amplify.configure({
  Auth: {
    region: "XX-XXXX-X",
    userPoolId: "XX-XXXX-X_abcd1234",
    userPoolWebClientId: "a1b2c3d4e5f6g7h8i9j0k1l2m3",
    identityPoolId: "XX-XXXX-X:XXXXXXXX-XXXX-1234-abcd-1234567890ab",
  },
  API: {
    endpoints: [
      {
        name: "apiName",
        endpoint: "https://12a3bcdefg.execute-api.us-east-1.amazonaws.com/dev/",
        region: "XX-XXXX-X"
      },
    ],
  },
  ssr: true,
});

This in turn allowed me to use API.get as expected in getServerSideProps:

export async function getServerSideProps({ req }) {
  const apiName = "apiName";
  const path = "items";

  const SSR = withSSRContext({ req });
  const response = await SSR.API.get(apiName, path);

  return {
    props: {
      response,
    },
  };
}

Removing the custom_header worked for mee ❤️

@nadetastic thank you! Just confirming, there are two issues:

1. SSR does not work with custom_header
2. External links don’t not work with SSR (there’s still another issue)

Hi, i’m facing same problem as @phstc and only solution found until now it’s:

in amplify.config.ts use a try catch so i can keep setting for all requests (SSR and client)

API: {
    endpoints: [
      {
        name: 'BE-API',
        endpoint: process.env.NEXT_PUBLIC_APIGATEWAY_URL,
        region: process.env.NEXT_PUBLIC_REGION,
        custom_header: async () => {
          try {
            const session = await Auth.currentSession();
            const token = session.getIdToken();
            const jwt = token.getJwtToken();

            return {
              Authorization: `Bearer ${jwt}`,
            };
          } catch (error) {
            return {};
          }
        },
      },
    ],
  },
  ssr: true,

for every fetch in getServerSideProps it must build headers as in config

...
const { Auth, API } = withSSRContext(context);
const session = await Auth.currentSession();
const token = session.getIdToken();
const jwt = token.getJwtToken();
const headers = { Authorization: `Bearer ${jwt}` };
result = await API.get('BE-API', '/endpoint', { headers });
return {props: result}

for client request (usually mutation as post, put) API works as expected

  const submit = useCallback(
    async (data) => {
      try {
          await API.post('BE-API', '/endopoint', { body: user });
      } catch (err: any) {
        // show error
      }
    },
    [],
  );

The error returned in SSR is “no current user” (as i recall). Cognito seems to be configured correctly.

Sorry for the confusion, I updated my comment.

@phstc I was finally able to get passed the "No current user" error.

It seems like the custom header in your amplify configure might be causing the issue. I did quite a bit of digging and logging and noticed that the error was actually being thrown from AuthClass and the more specific error was "Failed to get user from user pool"

I was able to get rid of the error by removing the entire custom_header section from Amplify.configure.

Personally, I am now getting 401/403 errors but I believe that is a different issue from how I set up this API.

Please let me know if this solves the issue for you as well

EDIT: Another note, it works successfully when I manually configure the project with the resources that I made through the CLI, so my 401/403 errors were definitely from some bad resource setup on my end.

My final configuration was as follows:

Amplify.configure({
  Auth: {
    region: "XX-XXXX-X",
    userPoolId: "XX-XXXX-X_abcd1234",
    userPoolWebClientId: "a1b2c3d4e5f6g7h8i9j0k1l2m3",
    identityPoolId: "XX-XXXX-X:XXXXXXXX-XXXX-1234-abcd-1234567890ab",
  },
  API: {
    endpoints: [
      {
        name: "apiName",
        endpoint: "https://12a3bcdefg.execute-api.us-east-1.amazonaws.com/dev/",
        region: "XX-XXXX-X"
      },
    ],
  },
  ssr: true,
});

This in turn allowed me to use API.get as expected in getServerSideProps:

export async function getServerSideProps({ req }) {
  const apiName = "apiName";
  const path = "items";

  const SSR = withSSRContext({ req });
  const response = await SSR.API.get(apiName, path);

  return {
    props: {
      response,
    },
  };
}

@phstc after some discussions with the team on this, I’m marking this as a bug. Thank you for all your time and feedback on this - truly appreciated. Let me know if you have any other questions

@phstc I was able to get this working as seen on my fork of your repo - https://github.com/nadetastic/cognito-amplify-cdk-10290/commit/0efcc007dfc35fccc408cff9173eb93caca12b37

In short, updated from using the custom header within amplifyConfig.API to setting it within the headers right before calling SSR.API.get(). This was pointed out before but you mentioned that you were still having issues after removing the custom header, but I’d like to note that I created new resources using the CDK stack you provided, so it doesn’t seem to be an issue with the CDK definition (backend looks unchanged in my repo, but I did modify it as you stated in the README just didn’t push the changes).

Are you able to try with the changes I have added? - https://github.com/nadetastic/cognito-amplify-cdk-10290

@phstc thank you very much for sharing the sample app! I will follow up soon

@tannerabread @nadetastic I was able to create a repo cognito-amplify-cdk-10290 with the code to reproduce the problem.

I added deploy instructions in the README to configure the sample code. Please, let me know if that works for you.

Once you run it locally npm run dev and then open http://localhost:3000, there will be two links:

One example is working using fetch discussed previously, and the other one is the broken one using SSR.API.

Hi @phstc following up here,

I also haven’t been able to reproduce your issue and I get the expected result when configuring similar to what you have. However one thing l’d like to confirm - on your Authorizer for API Gateway, are you specifying the Token Source?

@weisisheng for your question, you shouldn’t have to modify cookie config from aws-exports

Hi 👋 Closing this as resolved. If you are still experiencing this issue and in need of assistance, please feel free to comment and provide us with additional information so we can re-open this issue and be better able to assist you.

Thank you!

Hi 👋 @phstc!

I have reproduced this on the server with a manual configuration of some old cognito and API resources, but the problem does not happen if new resources are created from the Amplify CLI.

It also does not work for me by calling it in useEffect but I was able to obtain the resources from getServerSideProps with fetch.

I have a few follow up questions so that we can figure out the root cause:

1. Which type of Auth do you have set up for this project? API Key or Cognito?
2. If it is API key, what is the expiration on the API key? Is it expired?