Does Axios support Set-Cookie? Is it possible to authenticate through Axios HTTP request? - express

I'm trying to authenticate express API back-end using Axios HTTP request call.
I was able to see 'Set-Cookie' in the response header, but cookie was not set. Is it possible to set cookies through Axios HTTP calls?
Access-Control-Allow-Origin: *
Connection: keep-alive
Content-Length: 355
Content-Type: application/json; charset=utf-8
Date: Fri, 28 Sep 2018 05:59:01 GMT
ETag: W/"163-PAMc87SVHWkdimTJca7oRw"
Set-Cookie: token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...; Max-Age=3.6; Path=/; Expires=Fri, 28 Sep 2018 05:59:04 GMT; HttpOnly
X-Powered-By: Express

Try this out!
axios.get('your_url', {withCredentials: true}); //for GET
axios.post('your_url', data, {withCredentials: true}); //for POST
axios.put('your_url', data, {withCredentials: true}); //for PUT
axios.delete('your_url', data, {withCredentials: true}); //for DELETE
For more information on this from the axios docs:
"withCredentials indicates whether or not cross-site Access-Control requests should be made using credentials" - https://github.com/axios/axios
More detail on withCredentials:
https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/withCredentials

Yes you can set cookies by Axios. The cookies need to be passed into the headers object. You can send cookies in a get/post/put/delete/etc. request:
As suggested by Aaron:
axios.get('URL', {
withCredentials: true
});
axios.post('URL', data, {
withCredentials: true
});
axios.put('URL', data, {
withCredentials: true
});
axios.delete('URL', data, {
withCredentials: true
});
Or you may also try this:
axios.get(url, {
headers: {
Cookie: "cookie1=value; cookie2=value; cookie3=value;"
}
}).then(response => {
console.log(response);
});

In case anyone else faces the problem I've had,
Here's a repost of my answer on a similar question https://stackoverflow.com/a/62821342/8479303
In my case, the network panel showed that the response had the 'Set-Cookie' header, but in axios the header wouldn't show up, and the cookie was being set.
For me, the resolution was setting the Access-Control-Expose-Headers header.
For explanation, from this comment on an issue in the axios repository I was directed to this person's notes which led me to set the Access-Control-Expose-Headers header -- and now the cookie is properly setting in the client.
So, in Express.js, I had to add the exposedHeaders option to my cors middleware:
const corsOptions = {
//To allow requests from client
origin: [
"http://localhost:3001",
"http://127.0.0.1",
"http://104.142.122.231",
],
credentials: true,
exposedHeaders: ["set-cookie"],
};
...
app.use("/", cors(corsOptions), router);
It was also important that on the axios side I use the withCredentials config in following axios requests that I wanted to include the cookies.
ex/
const { data } = await api.get("/workouts", { withCredentials: true });

I tried setting withCredentials: true but was still getting this error:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://localhost:4000/users/register. (Reason: CORS request did not succeed).
CORS was configured to allow requests from the frontend port.
I had to change the default options for axios like so:
axios.defaults.withCredentials = true
And the issue was solved. No error and Set-Cookie working as expected.

cookie can't be touched, the thing is it gets bundled to request object after appended to the response object.
function sign(req,res){
res.cookie("x-token", signed, { maxAge: (new JWTService().jwtExpirySeconds *
1000) });
}
client after receiving this response just have to continue with requests, set-cookie in the name of "Cookie " will be bundled to those request, like this
caveat: when http cookie expires its is automatically removed and not bundled to request there after.

Related

Why is browser using cached response headers if they are not present in the actual response?

I realized that a response header would be present in the Network tab of the Chrome console even if that header wasn't set in express. I found this answer suggesting disallowing caching. What confuses me is why the cached response is still used even if a request is made to the server.
request from react
const baseURL = 'http://localhost:3001'
const axiosClient = axios.create({
baseURL,
withCredentials: true,
})
let accessToken
axiosClient.interceptors.response.use((response) => {
const { data, headers } = response
//store access token in memory
accessToken = headers['x-access-token']
console.log(accessToken)
// if (accessToken) axiosClient.defaults.headers['X-Access-Token'] = accessToken
return data
})
async me() {
return await axiosClient.get('/auth/me')
}
request reaches route
router.get('/me', (req, res) => {
// res.set('X-Access-Token', 'test 4')
res.send('me')
})
vscode debug console
res.getHeaders()
{x-powered-by: 'Express', access-control-allow-origin: 'http://localhost:3000', vary: 'Origin', access-control-allow-credentials: 'true', access-control-expose-headers: 'X-Access-Token'}
req.headers
{host: 'localhost:3001', connection: 'keep-alive', sec-ch-ua: '"Not?A_Brand";v="8", "Chromium";v="108", "Google Chrome";v="108"', accept: 'application/json, text/plain, */*', sec-ch-ua-mobile: '?0', …}
old token still appears in chrome
Since Chrome made a request to the server instead of just using the cached response (First, since there is no need to deliver the request to the origin server, then the closer the client and cache are, the faster the response will be), why isn't Chrome using the received response where the token header isn't present?

Nextjs pass cookie from external API and set on calling domain

I have a Nextjs app running at domain like https://client.mydomain.com that makes calls, from browser not getServerSideProps or micro api, to Express API at https://api.mydomain.com. The API returns a cookie (Secure, SameSite='none', long Expires), I can see the cookie in the response, and subsequent calls to the API from the browser will include the cookie correctly, but the cookie is not ever set on https://client.mydomain.com. So if I return to https://client.mydomain.com, the cookie is not present. Like it somehow pertains to the shared singleton axios instance.
How do I allow the cookie to pass through correctly from the API domain > client domain? > browser to be set on https://client.mydomain.com? I can extract the cookie from API in the axios call response in the client browser and manually set it via document.cookie of course, but sure I can simply allow it to pass through somehow from the API?
Express
https://api.mydomain.com
...
app.use(
cors({
origin: ['https://client.mydomain.com', 'https://localhost:80'],
credentials: true,
exposedHeaders: 'Set-Cookie',
}),
);
...
res.cookie('mycookie', 'hello', {
sameSite: 'none',
secure: true,
expires: tokenExpires,
});
...
Next.js App
https://client.mydomain.com
const response = await axios.get('/', {
withCredentials: true,
});
Response Header
set-cookie: mycookie=hello; Path=/; Expires=Fri, 29 Apr 2022 21:43:00 GMT; Secure; SameSite=None
Yet no cookie persisted if I check the application tab in chrome, or run document.cookie after the requests to API

How to enable CORS allow-origin header in express server with swagger-ui

My API server doesn't change or overwrite the Access-Control-Allow-Origin header.
I have an Angular 2+ application with an Express/Swagger-UI API.
The Access-Control-Allow-Origin header in the API cannot be '*' because I use 'withCredentials' in my requests and it's trigger an error on the browser.
I've used 'cors' for setting the CORS headers. Like this:
'use strict';
var configuration = require('./configuration');
var SwaggerExpress = require('swagger-express-mw');
var app = require('express')();
var mongoose = require('mongoose');
var bluebird = require('bluebird');
var bodyParser = require('body-parser');
var jwt = require('jsonwebtoken');
var compression = require('compression');
var cors = require('cors');
app.use(bodyParser.json({ limit: '50mb' }));
app.use(compression());
SwaggerExpress.create(config, function(err, swaggerExpress) {
if (err) { throw err; }
swaggerExpress.register(app);
var port = process.env.PORT || 10010;
mongoose.Promise = bluebird;
mongoose.connect(appConfig.dbConection());
mongoose.connection.on('error', console.error.bind(console, 'connection error: '));
mongoose.set('debug', true);
mongoose.connection.once('open', function() {
app.listen(port);
})
});
const swaggerUi = require('swagger-ui-express');
const YAML = require('yamljs');
const swaggerDocument = YAML.load('./api/swagger/swagger.yaml');
app.use('/api-docs', swaggerUi.serve, swaggerUi.setup(swaggerDocument));
var allowedOrigins = ['http://localhost:4200', 'http://127.0.0.1:10010'];
app.use(cors({
origin: (origin, callback) => {
if (!origin) return callback(null, true);
if (allowedOrigins.indexOf(origin) === -1) {
return callback(new Error('The CORS policy for this site does not allow the specified Origin'), false);
}
return callback(null, true);
},
exposedHeaders: ['Origin', 'X-Requested-With', 'Content-Type', 'Accept', 'Authorization', 'api_key', 'x-api-key'],
credentials: true
}));
The Access-Control-Allow-Origin should match the array of allowed hosts.
When I call the API from the browser, it first make an OPTIONS request, that look correct, like this:
Request URL: http://localhost:10010/v1/loginApp
Request Method: OPTIONS
Status Code: 204 No Content
Remote Address: [::1]:10010
Referrer Policy: no-referrer-when-downgrade
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: x-api-key
Access-Control-Allow-Methods: GET,HEAD,PUT,PATCH,POST,DELETE
Access-Control-Allow-Origin: http://localhost:4200
Access-Control-Expose-Headers: Origin,X-Requested-With,Content-Type,Accept,Authorization,api_key,x-api-key
Connection: keep-alive
Content-Length: 0
Date: Thu, 04 Apr 2019 08:25:53 GMT
Vary: Origin, Access-Control-Request-Headers
X-Powered-By: Express
But then it makes the GET/POST request, and then it has the default headers again:
Request URL: http://localhost:10010/v1/loginApp
Request Method: GET
Status Code: 200 OK
Remote Address: [::1]:10010
Referrer Policy: no-referrer-when-downgrade
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: Origin,X-Requested-With,Content-Type,Accept,Authorization,api_key,x-api-key
Content-Length: 770
Content-Type: application/json; charset=utf-8
Date: Thu, 04 Apr 2019 08:25:53 GMT
ETag: W/"302-BwX5DjK/lUY+ueP6UZ9TgWOTw/s"
Vary: Origin
X-Powered-By: Express
I think something (probably swagger-UI) is overwriting my headers configuration, but I can't figure it out.
You need to register your CORS middleware before the Swagger GET/POST handlers.
The OPTIONS request is succeeding because Swagger doesn't register an OPTIONS handler, so the request reaches the middleware.
The GET/POST requests are failing before the Swagger handlers accept the request before it reaches the CORS middleware.
Move app.use(cors({... so it is before app.use('/api-docs', swaggerUi....
It seems as if swagger-express-mw comes with CORS support built-in, see swagger_controllers in your config/default.yaml. I had the same issue and fixed it by removing cors from there.
Like you, I suspect it's overwriting the Access-Control-Allow-Origin header but didn't have time to check it properly.

Ionic CORS Error, But Server Has CORS Enabled

I have an Ionic 4 app that uses a lambda API hosted on AWS. CORS is enabled on the API Gateway. The following snippet is from a curl request to the API.
< content-type: application/json
< content-length: 42
< date: Sat, 16 Feb 2019 02:19:25 GMT
< x-amzn-requestid: 47a5fcac-3191-11e9-af42-d387861aa6ad
< access-control-allow-origin: *
< access-control-allow-headers: Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token
< x-amz-apigw-id: VK7vFGc4oAMFTqg=
< access-control-allow-methods: POST,OPTIONS
This post discusses a few possible workarounds (change content type, etc.), but they don't work.
Changing the Content-Type header to text/plain or removing that header altogether makes no difference.
The following error is also presented on the Ionic console
Cross-Origin Read Blocking (CORB) blocked cross-origin response
https://mycoolapi.com/GetLegal with MIME type application/json.
See https://www.chromestatus.com/feature/5629709824032768 for more details.
The following is my service code.
getLegal(data: any) {
return new Promise((resolve, reject) => {
let httpHeaders = new HttpHeaders().set('Content-Type', 'application/json');
this.httpClient.post(this.apiUrl+'/GetLegal', JSON.stringify(data), {
headers: httpHeaders,
})
.subscribe(res => {
resolve(new LegalResponse(res));
}, (err) => {
console.log("Oops, there has been an error")
reject(err);
});
});
}
Help?
This ended up being a bug on the Amazon side. The curl snippet was from a GET method, which was sending the CORS headers. The POST method was not. After redeploying the API without changing anything, the GET method was no longer sending the CORS headers and the POST method was. The application is working, for now.

Set cookies for cross origin requests

How to share cookies cross origin? More specifically, how to use the Set-Cookie header in combination with the header Access-Control-Allow-Origin?
Here's an explanation of my situation:
I am attempting to set a cookie for an API that is running on localhost:4000 in a web app that is hosted on localhost:3000.
It seems I'm receiving the right response headers in the browser, but unfortunately they have no effect. These are the response headers:
HTTP/1.1 200 OK
Access-Control-Allow-Origin: http://localhost:3000
Vary: Origin, Accept-Encoding
Set-Cookie: token=0d522ba17e130d6d19eb9c25b7ac58387b798639f81ffe75bd449afbc3cc715d6b038e426adeac3316f0511dc7fae3f7; Max-Age=86400; Domain=localhost:4000; Path=/; Expires=Tue, 19 Sep 2017 21:11:36 GMT; HttpOnly
Content-Type: application/json; charset=utf-8
Content-Length: 180
ETag: W/"b4-VNrmF4xNeHGeLrGehNZTQNwAaUQ"
Date: Mon, 18 Sep 2017 21:11:36 GMT
Connection: keep-alive
Furthermore, I can see the cookie under Response Cookies when I inspect the traffic using the Network tab of Chrome's developer tools. Yet, I can't see a cookie being set in in the Application tab under Storage/Cookies. I don't see any CORS errors, so I assume I'm missing something else.
Any suggestions?
Update I:
I'm using the request module in a React-Redux app to issue a request to a /signin endpoint on the server. For the server I use express.
Express server:
res.cookie('token', 'xxx-xxx-xxx', { maxAge: 86400000, httpOnly: true, domain: 'localhost:3000' })
Request in browser:
request.post({ uri: '/signin', json: { userName: 'userOne', password: '123456'}}, (err, response, body) => {
// doing stuff
})
Update II:
I am setting request and response headers now like crazy now, making sure that they are present in both the request and the response. Below is a screenshot. Notice the headers Access-Control-Allow-Credentials, Access-Control-Allow-Headers, Access-Control-Allow-Methods and Access-Control-Allow-Origin. Looking at the issue I found at Axios's github, I'm under the impression that all required headers are now set. Yet, there's still no luck...
Cross site approach
To allow receiving & sending cookies by a CORS request successfully, do the following.
Back-end (server) HTTP header settings:
Set the HTTP header Access-Control-Allow-Credentials value to true.
Make sure the HTTP headers Access-Control-Allow-Origin and Access-Control-Allow-Headers are set. Don't use a wildcard *. When you set the allowed origin make sure to use the entire origin including the scheme, i.e. http is not same as https in CORS.
For more info on setting CORS in express js read the docs here.
Cookie settings:
Cookie settings per Chrome and Firefox update in 2021:
SameSite=None
Secure
When doing SameSite=None, setting Secure is a requirement. See docs on SameSite and on requirement of Secure. Also note that Chrome devtools now have improved filtering and highlighting of problems with cookies in the Network tab and Application tab.
Front-end (client): Set the XMLHttpRequest.withCredentials flag to true, this can be achieved in different ways depending on the request-response library used:
ES6 fetch() This is the preferred method for HTTP. Use credentials: 'include'.
jQuery 1.5.1 Mentioned for legacy purposes. Use xhrFields: { withCredentials: true }.
axios As an example of a popular NPM library. Use withCredentials: true.
Proxy approach
Avoid having to do cross site (CORS) stuff altogether. You can achieve this with a proxy. Simply send all traffic to the same top level domain name and route using DNS (subdomain) and/or load balancing. With Nginx this is relatively little effort.
This approach is a perfect marriage with JAMStack. JAMStack dictates API and Webapp code to be completely decoupled by design. More and more users block 3rd party cookies. If API and Webapp can easily be served on the same host, the 3rd party problem (cross site / CORS) dissolves. Read about JAMStack here or here.
Sidenote
It turned out that Chrome won't set the cookie if the domain contains a port. Setting it for localhost (without port) is not a problem. Many thanks to Erwin for this tip!
Note for Chrome Browser released in 2020.
A future release of Chrome will only deliver cookies with cross-site
requests if they are set with SameSite=None and Secure.
So if your backend server does not set SameSite=None, Chrome will use SameSite=Lax by default and will not use this cookie with { withCredentials: true } requests.
More info https://www.chromium.org/updates/same-site.
Firefox and Edge developers also want to release this feature in the future.
Spec found here: https://datatracker.ietf.org/doc/html/draft-west-cookie-incrementalism-01#page-8
In order for the client to be able to read cookies from cross-origin requests, you need to have:
All responses from the server need to have the following in their header:
Access-Control-Allow-Credentials: true
The client needs to send all requests with withCredentials: true option
In my implementation with Angular 7 and Spring Boot, I achieved that with the following:
Server-side:
#CrossOrigin(origins = "http://my-cross-origin-url.com", allowCredentials = "true")
#Controller
#RequestMapping(path = "/something")
public class SomethingController {
...
}
The origins = "http://my-cross-origin-url.com" part will add Access-Control-Allow-Origin: http://my-cross-origin-url.com to every server's response header
The allowCredentials = "true" part will add Access-Control-Allow-Credentials: true to every server's response header, which is what we need in order for the client to read the cookies
Client-side:
import { HttpInterceptor, HttpXsrfTokenExtractor, HttpRequest, HttpHandler, HttpEvent } from "#angular/common/http";
import { Injectable } from "#angular/core";
import { Observable } from 'rxjs';
#Injectable()
export class CustomHttpInterceptor implements HttpInterceptor {
constructor(private tokenExtractor: HttpXsrfTokenExtractor) {
}
intercept(req: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> {
// send request with credential options in order to be able to read cross-origin cookies
req = req.clone({ withCredentials: true });
// return XSRF-TOKEN in each request's header (anti-CSRF security)
const headerName = 'X-XSRF-TOKEN';
let token = this.tokenExtractor.getToken() as string;
if (token !== null && !req.headers.has(headerName)) {
req = req.clone({ headers: req.headers.set(headerName, token) });
}
return next.handle(req);
}
}
With this class you actually inject additional stuff to all your request.
The first part req = req.clone({ withCredentials: true });, is what you need in order to send each request with withCredentials: true option. This practically means that an OPTION request will be send first, so that you get your cookies and the authorization token among them, before sending the actual POST/PUT/DELETE requests, which need this token attached to them (in the header), in order for the server to verify and execute the request.
The second part is the one that specifically handles an anti-CSRF token for all requests. Reads it from the cookie when needed and writes it in the header of every request.
The desired result is something like this:
For express, upgrade your express library to 4.17.1 which is the latest stable version. Then;
In CorsOption: Set origin to your localhost url or your frontend production url and credentials to true
e.g
const corsOptions = {
origin: config.get("origin"),
credentials: true,
};
I set my origin dynamically using config npm module.
Then , in res.cookie:
For localhost: you do not need to set sameSite and secure option at all, you can set httpOnly to true for http cookie to prevent XSS attack and other useful options depending on your use case.
For production environment, you need to set sameSite to none for cross-origin request and secure to true. Remember sameSite works with express latest version only as at now and latest chrome version only set cookie over https, thus the need for secure option.
Here is how I made mine dynamic
res
.cookie("access_token", token, {
httpOnly: true,
sameSite: app.get("env") === "development" ? true : "none",
secure: app.get("env") === "development" ? false : true,
})
Pim's answer is very helpful. In my case, I have to use
Expires / Max-Age: "Session"
If it is a dateTime, even it is not expired, it still won't send the cookie to the backend:
Expires / Max-Age: "Thu, 21 May 2020 09:00:34 GMT"
Hope it is helpful for future people who may meet same issue.
In the latest chrome standard, if CORS requests to bring cookies, it must turn on samesite = none and secure, and the back-end domain name must turn on HTTPS,
frontend
`await axios.post(`your api`, data,{
withCredentials:true,
})
await axios.get(`your api`,{
withCredentials:true,
});`
backend
var corsOptions = {
origin: 'http://localhost:3000', //frontend url
credentials: true}
app.use(cors(corsOptions));
const token=jwt.sign({_id:user_id},process.env.JWT_SECRET,{expiresIn:"7d"});
res.cookie("token",token,{httpOnly:true});
hope it will work.
After more then a day of trying all your suggestions and many more, I surrender.
Chrome just does not accept my cross domain cookies on localhost.
No errors, just silently ignored.
I want to have http only cookies to safer store a token.
So for localhost a proxy sounds like the best way around this. I haven't really tried that.
What I ended up doing, maybe it helps someone.
Backend (node/express/typescript)
set cookie as you normally would
res.status(200).cookie("token", token, cookieOptions)
make a work around for localhost
// if origin localhost
response.setHeader("X-Set-Cookie", response.getHeader("set-cookie") ?? "");
Allow x-set-cookie header in cors
app.use(cors({
//...
exposedHeaders: [
"X-Set-Cookie",
//...
]
}));
Frontend (Axios)
On the Axios response
remove the domain= so it's defaulted.
split multiple cookies and store them locally.
// Localhost cookie work around
const xcookies = response.headers?.["x-set-cookie"];
if(xcookies !== undefined){
xcookies
.replace(/\s+Domain=[^=\s;]+;/g, "")
.split(/,\s+(?=[^=\s]+=[^=\s]+)/)
.forEach((cookie:string) => {
document.cookie = cookie.trim();
});
}
Not ideal, but I can move on with my life again.
In general this is just been made to complicated I think :-(
Update my use case maybe we can resolve it?
It's a heroku server with a custom domain.
According to this article that should be okay
https://devcenter.heroku.com/articles/cookies-and-herokuapp-com
I made an isolated test case but still no joy.
I'm pretty sure I've seen it work in FireFox before but currently nothing seems to work, besides my nasty work around.
Server Side
app.set("trust proxy", 1);
app.get("/cors-cookie", (request: Request, response: Response) => {
// http://localhost:3000
console.log("origin", request.headers?.["origin"]);
const headers = response.getHeaders();
Object.keys(headers).forEach(x => {
response.removeHeader(x);
console.log("remove header ", x, headers[x]);
});
console.log("headers", response.getHeaders());
const expiryOffset = 1*24*60*60*1000; // +1 day
const cookieOptions:CookieOptions = {
path: "/",
httpOnly: true,
sameSite: "none",
secure: true,
domain: "api.xxxx.nl",
expires: new Date(Date.now() + expiryOffset)
}
return response
.status(200)
.header("Access-Control-Allow-Credentials", "true")
.header("Access-Control-Allow-Origin", "http://localhost:3000")
.header("Access-Control-Allow-Methods", "GET,HEAD,OPTIONS,POST,PUT")
.header("Access-Control-Allow-Headers", "Origin, X-Requested-With, Content-Type, Accept")
.cookie("test-1", "_1_", cookieOptions)
.cookie("test-2", "_2_", {...cookieOptions, ...{ httpOnly: false }})
.cookie("test-3", "_3_", {...cookieOptions, ...{ domain: undefined }})
.cookie("test-4", "_4_", {...cookieOptions, ...{ domain: undefined, httpOnly: false }})
.cookie("test-5", "_5_", {...cookieOptions, ...{ domain: undefined, sameSite: "lax" }})
.cookie("test-6", "_6_", {...cookieOptions, ...{ domain: undefined, httpOnly: false, sameSite: "lax" }})
.cookie("test-7", "_7_", {...cookieOptions, ...{ domain: "localhost"}}) // Invalid domain
.cookie("test-8", "_8_", {...cookieOptions, ...{ domain: ".localhost"}}) // Invalid domain
.cookie("test-9", "_9_", {...cookieOptions, ...{ domain: "http://localhost:3000"}}) // Invalid domain
.json({
message: "cookie"
});
});
Client side
const response = await axios("https://api.xxxx.nl/cors-cookie", {
method: "get",
withCredentials: true,
headers: {
"Accept": "application/json",
"Content-Type": "application/json",
}
});
Which yields the following reponse
I see the cookies in the Network > request > cookies Tab.
But no cookies under Application > Storage > Cookies nor in document.cookie.
Pim's Answer is very helpful,
But here is an edge case I had gone through,
In my case even though I had set the Access-Control-Allow-Origin to specific origins in BE , In FE I received it as * ; which was not allowed
The problem was, some other person handled the webserver setup,
in that, there was a config to set the Access-Control-* headers which was overriding my headers set from BE application
phew.. took a while to figure it out .
So, if there is mismatches in what you set and what you received, Check your web server configs also.
Hope this would help
for me regarding the sameSite property, after enabling CORS I also add "CookieSameSite = SameSiteMode.None"
to the CookieAuthenticationOptions in the Startup file
app.UseCookieAuthentication(new CookieAuthenticationOptions
{
.....
CookieSameSite = SameSiteMode.None,
.....
}
This is an answer to "Lode Michels" from above regarding CORS cookie with the Heroku server, (and for other cloud providers, like AWS)
The reason your CORS cookie can't be set is because Heroku strip down SSL certificate at Load Balancer, so when you try to set the "secure" cookie at the server, it fails since it's no longer from the secure connection.
You can explicitally specify if the connection is secure, rather than the cookie module examining request.
https://github.com/pillarjs/cookies
with koa, add this:
ctx.cookies.secure = true;
edit: I can't comment on that answer directly due to lower than 50 reputation
This code worked for me
In the backend
Set credentials to true in your corsOptions:
const corsOptions = {
credentials: true,
};
Set cookies before sending requests:
res.cookie('token', 'xxx-xxx-xxx', {
maxAge: 24*60*60*1000, httpOnly: true,
SameSite:"None" })
In the frontend
Request in browser (using axios):
axios.post('uri/signin',
JSON.stringify({ username: 'userOne',
password: '123456'}),.
{withCredentials:true})
.the(result
=>console.log(result?.data))
.catch(err => console.log(err))