Add support for geographic location in Middleware about open-next HOT 9 CLOSED

@fwang This can be closed; the geo data is available now.

from open-next.

Added in v1.2.0

from open-next.

@Makisuo request.geo does not work with OpenNext V3 at the moment. I'll add it back in the next releases, but it will require an update in the ion construct as well.
Right now you can use the cloudfront headers https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/adding-cloudfront-headers.html#cloudfront-headers-viewer-location

from open-next.

I tried changing the policy to origin request (redirects are changing the host to the middleware lambda domain, we'll need to update the x-forwarded-host to the original host so the user stays on the same domain). I'm still getting undefined geo data after the change...

I'm setting the header Cache-Control: public,s-maxage=0 so it behaves like "viewer request"

from open-next.

In the NextjsSite, can you add the CloudFront-Viewer-Country, etc... to the createCloudFrontServerCachePolicy function for middleware-function?

And in createCloudFrontDistributionForRegional, can you add this to the serverBehavior origin:

customHeaders: { 'x-origin-url': appDomain || fnUrl.url }

The Lambda Edge needs to read from the customHeaders field and set the host to that value and set the x-forwarded-host to itself.

ref:
https://github.com/jetbridge/cdk-nextjs/blob/main/assets/lambda%40edge/LambdaOriginRequest.ts#L32
https://github.com/jetbridge/cdk-nextjs/blob/main/src/NextjsDistribution.ts#L312

As for the middleware.ts redirects, I'm getting redirected to the raw lambda URL instead of my domain. The headers.location is not correctly set. I'm not sure if solving for the above will address the issue.

from open-next.

I've been experimenting w/ latency issues and hacked my way around fixing the latency by moving the server-adapter to origin-request edge lambda to the same distribution. Adding option for user to set edge mode in NextjsSite will kill 2 birds w/ 1 stone: fast latency going from middleware to server (both using L@E) and gives the server handler access to the geo data.

from open-next.

@khuezy just to clarify, r u accessing the geo data via CloudFront-* headers? Or are they available in NextRequest's geo field (ie. request.geo.city)?

from open-next.

@fwang I seen them in the CloudFront-* headers. Vercel has some logic to package that nicely into the request.geo, which open-next might want to do.

from open-next.

Just stumbled on this and it seems like this isn't working anymore. Using SST 3.0.11 geo headers are always empty for me in my next middleware

from open-next.