8

We are using AWS Amplify for our NextJS web app and keep receiving error when ever I try to load the application once deployed to Amplify. Locally there is no issue.

enter image description here

I am using Amplify's default Auth configuration, with basic email and password auth. It looks like it could be related to the Amplify cookie being set in the header but I cannot find any documentation within AWS to prevent this or reduce the amount of information passed with the header. Any help would be appreciated.

georgeperry
  • 184
  • 2
  • 4
  • 13
  • 1
    Facing the same issue. Not sure how to fix this. For me, it's a simple ISR App on Amplify without Authentication. It works in incognito though. – sohammondal May 24 '22 at 07:42
  • Any fixes found yet? – Shiraaz Jun 29 '22 at 06:33
  • Nothing the actually fix it but I'm pretty certain its due to testing different environments of the same application on the same browser. None of our production users have experienced the issue and it only seems to be affecting devs and QA who are running development and staging environments. – georgeperry Jun 30 '22 at 08:39
  • @georgeperry precisely. this issue was happening to internal users who were logged into different environments. – sohammondal Aug 31 '22 at 10:23
  • @Shiraaz check out my answer & see if it solves your problem - https://stackoverflow.com/a/73554409/6335249 – sohammondal Aug 31 '22 at 10:25
  • @georgeperry in that case we should not get this issue in chrome incognito, but we are getting in incognito as well. – Rams Aug 29 '23 at 05:42

3 Answers3

4

I have faced the same issue and was able to solve it. Here's how -

  1. Identify the CloudFront Distribution ID for your app. You can find it in the Deploy logs of your app build console.

AWS Amplify Build Console

  1. Search & open that particular CF Distribution and go to the Behaviours tab.

  2. Select the Default behaviour (5th one in my case) and hit Edit.

Cloudfront Distribution Console > Behaviours Tab

  1. Scroll down to the Cache key and origin requests section. Here you will find settings to control what's included in the headers of the request that goes to the server. In my case, I didn't need any Cookies so I chose None, and it solved the issue for me. In your case, you can do the same or pick what all info needs to be in the headers.

Cloudfront Distribution Console > Behaviours Tab Edit

sohammondal
  • 635
  • 6
  • 12
  • 2
    not able to see Distribution Id on my side, is there any other way to disable cookies? – Rupinderpal Thind Sep 03 '22 at 07:11
  • @RupinderpalThind I'm unaware of other ways. Did you check this - https://github.com/aws-amplify/amplify-hosting/issues/2486#issuecomment-1057296662? – sohammondal Sep 04 '22 at 13:06
  • This solved the issue for me but @sohammondal can you tell me why its happening though? I thought it was something to do with cognito tokens first, but what is it actually have to do with or why does it happen? – Shiraaz Sep 26 '22 at 05:59
  • 1
    @Shiraaz I also thought the issue on my side was happening because of JWT but that's not the case. At my company, we've 3 envs - prod, beta, dev. After authentication, we store the JWT in cookies and the config is such that cookies can be shared across sub-domains. So from prod, I can access cookies from beta & dev, which is unnecessary. Those cookies were sent to CF edge servers via headers and their total size is greater than 8192 bytes. Now, because of the CF header size restriction, we are getting the above error. The root cause of the issue is the Cookie config of our web apps & not CF. – sohammondal Oct 04 '22 at 06:08
0

Check to see if there are any unnecessary cookies for that domain.

I was getting this error (on a site I don't own). I took a look at the request headers and found a very large number of cookies (several dozen) for the site's domain. I cleaned up the cookies which seemed non-critical and the error went away.

As the error implies, the size of the entire request header section is above 8192 bytes. Request headers include the accept headers, the user agent, the cookies, etc. and all combined can get rather large. Large headers look malicious to some WAFs. I once had a single user having trouble with our site. Turns out they were a polyglot and had configured their browser to accept several dozen languages causing their accept-language header to be suspiciously long, and the WAF refused to proxy the request.

SonOfSofaman
  • 21
  • 1
  • 3
0

I faced the same issue using Nextjs, amplify and an external Auth provider.

The problem is that AWS S3 service has a request header maximum allowed size of 8192 bytes, so when ever you try to access the static generated pages of Nextjs it returns that error. This has already been asked here

In my case, I was using an external Auth provider and I was able to solve the issue configuring the cookies only for the '/api/' path. That way the Auth cookies are sent only to the Nextjs api endpoints, so your request header is lighter whenever you try to get the static pages.

Sebastian Milhas
  • 1