My stack is the following: NestJS backend (Express under the hood) deployed on Elastic Beanstalk, NextJS frontend deployed on AWS Amplify, CloudFront as CDN, and I can't get Set-Cookie header back to the frontend NextJS app, nor a cookie is being set.
FE and BE are on a different domains.
Locally everything works fine, when FE and BE apps are local, eg. I'm getting Set-Cookie and a cookie is stored in the browser. When FE is local and BE is deployed, it doesn't work as expected also when communicating between the two. CORS is being set up and there's no error there. Cookie options seems right too.
On the backend, CORS has been set with 3 options, out of the factory method, eg. app.enableCors({...}):
explicit origin (no wildcard) - works with allowed credentials turned on
credentials set to true - allow credentials header
allowed headers
So, CORS is working, no error there, just not returning Set-Cookie header when deployed.
For cookie, I'm using cookie-parser npm module, and having set up the following options for the cookie when returning the response for POST /auth/login request:
httpOnly: true - no script reading
maxAge (1 day into the future from request time)
sameSite: 'none' - cross-site enabled
secure: true - https (required for cross-site)
On the frontend, I'm using NextJS with axios npm module to fetch an API. Also, I'm having credentials set to true.
I tried to update CORS settings on load balancers, eg. proxy for the backend, and was doing a lot of research on Stack Overflow and other platforms, but couldn't find a solution. Most solutions mention that some options are missing for the backend, like CORS and a cookie settings, and credentials: true for the frontend. But as mentioned before, seems I got that covered. CloudFront settings didn't help either. CloudFront caching policy - didn't help. Something is missing or am doing it wrong.
Everything points that the AWS has to be set up properly(default/basic settings), but I don't know what excatly. Any help?
Related
Edit:
After investigating this further, it seems cookies are sent correctly on most API requests. However something happens in the specific request that checks if the user is logged in and it always returns null. When refreshing the browser a successful preflight request is sent and nothing else, even though there is a session and a valid session cookie.
Original question:
I have a NextJS frontend authenticating against a Keystone backend.
When running on localhost, I can log in and then refresh the browser without getting logged out, i.e. the browser reads the cookie correctly.
When the application is deployed on an external server, I can still log in, but when refreshing the browser it seems no cookie is found and it is as if I'm logged out. However if I then go to the Keystone admin UI, I am still logged in.
In the browser settings, I can see that for localhost there is a "keystonejs-session" cookie being created. This is not the case for the external server.
Here are the session settings from the Keystone config file.
The value of process.env.DOMAIN on the external server would be for example example.com when Keystone is deployed to admin.example.com. I have also tried .example.com, with a leading dot, with the same result. (I believe the leading dot is ignored in newer specifications.)
const sessionConfig = {
maxAge: 60 * 60 * 24 * 30,
secret: process.env.COOKIE_SECRET,
sameSite: 'lax',
secure: true,
domain: process.env.DOMAIN,
path: "/",
};
const session = statelessSessions(sessionConfig);
(The session object is then passed to the config function from #keystone-6/core.)
Current workaround:
I'm currently using a workaround which involves routing all API requests to '/api/graphql' and rewriting that request to the real URL using Next's own rewrites. Someone recommended this might work and it does, sort of. When refreshing the browser window the application is still in a logged-out state, but after a second or two the session is validated.
To use this workaround, add the following rewrite directive to next.config.js
rewrites: () => [
{
source: '/api/graphql',
destination:
process.env.NODE_ENV === 'development'
? `http://localhost:3000/api/graphql`
: process.env.NEXT_PUBLIC_BACKEND_ENDPOINT,
},
],
Then make sure you use this URL for queries. In my case that's the URL I feed to createUploadLink().
This workaround still means constant error messages in the logs since relative URLs are not supposed to work. I would love to see a proper solution!
It's hard to know what's happening for sure without knowing more about your setup. Inspecting the requests and responses your browser is making may help figure this out. Look in the "network" tab in your browser dev tools. When you make make the request to sign in, you should see the cookie being set in the headers of the response.
Some educated guesses:
Are you accessing your external server over HTTPS?
They Keystone docs for the session API mention that, when setting secure to true...
[...] the cookie is only sent to the server when a request is made with the https: scheme (except on localhost)
So, if you're running your deployed env over plain HTTP, the cookie is never set, creating the behaviour you're describing. Somewhat confusingly, in development the flag is ignored, allowing it to work.
A similar thing can happen if you're deploying behind a proxy, like nginx:
In this scenario, a lot of people choose to have the proxy terminate the TLS connection, so requests are forwarded to the backend over HTTP (but on a private network, so still relatively secure). In that case, you need to do two things:
Ensure the proxy is configured to forward the X-Forwarded-Proto header, which informs the backend which protocol was used originally request
Tell express to trust what the proxy is saying by configuring the trust proxy setting
I did a write up of this proxy issue a while back. It's for Keystone 5 (so some of the details are off) but, if you're using a reverse proxy, most of it's still relevant.
Update
From Simons comment, the above guesses missed the mark 😠but I'll leave them here in case they help others.
Since posting about this issue a month ago I was actually able to work around it by routing API requests via a relative path like '/api/graphql' and then forwarding that request to the real API on a separate subdomain. For some mysterious reason it works this way.
This is starting to sound like a CORS or issue
If you want to serve your front end from a different origin (domain) than the API, the API needs to return a specific header to allow this. Read up on CORS and the Access-Control-Allow-Origin header. You can configure this setting the cors option in the Keystone server config which Keystone uses to configure the cors package.
Alternatively, the solution of proxying API requests via the Next app should also work. It's not obvious to me why your proxying "workaround" is experiencing problems.
I have a django backend and a Vue 3 frontend.
For handling some request, my backend needs an 'Id-Client' header in the headers of the request.
Developing my BE everything worked like a charm, but now that I'm writing the FE I'm encountering some issues.
As I said before, I need to append an header to my headers in every request.
So the first step was the following:
// Note that the idClient is dynamic and can change.
this.$axios.setHeader('Id-Client', idClient)
const data = await this.$axios.$get(url)
But I can't get it to work, if I try to send that request, my GET request becomes (I don't know why) a OPTIONS request and I get the error "cross origin resource sharing error: HeaderDisallowedByPreflightResponse"
Instead if I remove the set header
// this.$axios.setHeader('Id-Client', idClient)
const data = await this.$axios.$get(url)
The server just respond me correctly giving me the error that the request is missing the 'Id-Client' in the header.
I also have a few request that don't need the 'Id-client' header and those request work, so I don't think is a CORS problem.
Well but is looks like CORS issue. CORS policies are not triggered by simple requests. By adding custom header, your requests are no longer simple and trigger CORS policies (sending OPTIONS before GET)
Your only option is to configure your backend server to reply to OPTIONS requests with the correct headers - Access-Control-Allow-Origin and Access-Control-Allow-Headers (server telling the browser "yes, im ok to accept particular custom header")
IF (and only if) you are planning to serve your Vue SPA from the same API server in production (same origin), you can avoid similar CORS issues during development by using Webpack Dev server Proxy - your SPA will send API requests to Webpack Dev Server (used for developing SPA) and Proxy will route it to your Django dev server. That way all request from your SPA are to the same origin and you don't need to care about CORS at all...
I'm trying to connect my local frontend to our development backend hosted in aws.
Everything used to work, and I'm going crazy trying to figure out what happened.
The issue is that the request to the backend isn't passing along the cookie we use for authentication.
We have cors setup and it appears to be working correctly. The Options call returns everything I'd expect
.
but the request just doesn't contain the cookie.
I'm setting the cookie via javascript in the frontend code rather than having the server itself set it. This setup used to work idk why it doesn't anymore.
What are the reasons why a browser wouldn't pass a cookie along?
My checklist includes:
ensuring Access-Control-Allow-Credentials is passed back from the Options request
ensure withCredentials is set on the frontend making the request
ensuring the cookie domain is set to /
We recently added some CSRF protection but I disabled that and still can't get the cookie to be sent.
A soapui call to the backend works just fine.
The issue lied in the samesite cookie.
I deployed my development server to explicitly set samesite=none and things are working again.
axios({
method: "get",
withCredentials: true,
});
adding withCredentials:true worked for me
I have a zuul routing app deployed on the cloud. Below in my application.yml
---
spring:
profiles: default
zuul:
routes:
cloud:
path: /cardsvcs/acs/**
sensitiveHeaders:
url: https://vst0.mapi.checkFin.com/
stripPrefix: false
ribbon:
eureka:
enabled: false
Routing works perfectly fine and I also get the response headers back from the back end service. The requestContext originResponseHeaders also have all the cookies as part of setCookie header. But these cookies are not visible on the Postman response after routing.
Do we need to gets the cookies from this header in the filter and map them again?
Please try the below.
zuul.sensitiveHeaders: Authorization
The sentive-headers that are configured in zuul are not passed to downstream servers. And below three headers are defaults.
zuul.sensitiveHeaders: Cookie,Set-Cookie,Authorization
To pass cookie related headers to your downstream server, you need to redefine above propeprties.
Please refer to the section 'Cookies and Sensitive Headers' in the the linked doc : http://cloud.spring.io/spring-cloud-static/Dalston.RELEASE/
I am trying to build an app where users upload content on their browsers to an S3 bucket through CloudFront. I have enabled CORS on the S3 bucket and ensured that the AllowedOrigin is set to *. I can successfully push content from a browser to the S3 bucket directly so I know that CORS on S3 is configured correctly. Now, I am trying to do the same with browser -> CloudFront -> S3. CloudFront always rejects the pre-flight OPTIONS method request with a 403 forbidden response.
I have the following options enabled on CloudFront:
Allowed HTTP Methods: GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE
Whitelist Headers: Access-Control-Request-Headers,
Access-Control-Request-Method, Origin OPTIONS requests are disabled
from the "Cached HTTP Methods"
CloudFront apparently now supports CORS but has anyone got it working for an HTTP method OPTIONS request? I tried asking this on the AWS forums but no responses.
Have your try adding a CNAME alias for your cloudfront domain ??
After setting up the CNAME alias, you can set the cookies on the base domain, then you will be able to pass your cookie.
Let's put more detail to it in case people want to know what would be the next step is, let's use the following example :-
You are developing on my.fancy.site.mydomain.com
Your Cloudfront CNAME alias is content.mydomain.com
Make sure you set your cloudfront signed cookies to .mydomain.com from your fancy app
From this point on, you are able to pass the cookie for the CF.
One quick way to test if your cookie is set appropriately, try to get your assets URL, and put the url in the browser directly. If the cookie set correctly, you will be able to access the file directly.
If you are using javascript to get the cdn assets, make sure in your JS code, you need to pass withCredentials option, or it won't work. For example, if you are using jQuery, you will need something like the following :-
$.ajax({
url: a_cross_domain_url,
xhrFields: {
withCredentials: true
}
});
And if the request is successful, you should get a response header from CloudFront with "Access-Control-blah-blah".
Hope it helps people if they search this answer.
I found a very similar issue. The CloudFront distribution was not sending the header information to S3. You can test this easily via:
curl -i -H "Origin: http://YOUR-SITE-URL" http://S3-or-CLOUDFRONT-URL | grep Access
If you have the same problem, you can see my solution here:
AWS S3 + CloudFront gives CORS errors when serving images from browser cache