We are currently up against an error with our client/api cookie generation. We are using Angular 12 and NGINX for a frontend server running with SSL on a subdomain of cms.domain.co.uk; the backend is running node.js with pm2 on a subdomain of api.domain.co.uk:3067 with SSL.

Our Backend nodejs file has the following CORS options snippet:

const app = express();
app.use(express.json());
app.use(cookieParser());
app.use(cors({
    origin: 'https://cms.domain.cloud',
    credentials: true,
    methods: 'GET, POST, OPTIONS',
    allowedHeaders: 'Origin, Content-Type, X-Auth-Token, Set-Cookie, Authorisation, Accept'
}));

We are setting the cookie in the node.js file as follows:

response.cookie('LoginCookie', sid, {httpOnly: true, secure: true, SameSite: "none"});

We have tried every feasible combination of origins, tags, and policies and we are now officially stumped. Excuse our naivety in CORS as we have come from non-cross origin background.

The responsive header from the server contains the set-cookie tag but the cookie isn't being set in the browser, allow credential controls is set to true in both the POST and OPTIONS as well as having the origin set to avoid CORS errors.

This is the pre-flight OPTIONS header sent:

1

This is the POST header sent with the Set-Cookie tag:

2

By starting another window of chrome with the using chrome.exe --user-data-dir="C:/Chrome dev session" --disable-web-security, the browser acknowledge the existence of the cookie in one section but not in the other:

3

Any feedback or help would be greatly appreciated! Thanks!

CodePudding user response：

An alternative is to retrieve de value of the 'LoginCookie' key Set-Cookie header, and store it to browser by document.cookie.setItem( 'LoginCookie', <data>)

CodePudding user response：

Thank you to both comments so far; we have tried setting the httpOnly flag to false and it doesn’t allow the cookie to be saved client side still - furthermore, we need the cookie to be accessible client side as it needs to be returned to the server on every consecutive call.

In regards to storing it manually; we did consider this (just returning the JSON value and storing as you suggested) but first we’re trying to have it work with CORS for convenience in the future. We think we’re either missing something glaringly obvious (likely), or CORS is incompatible between two subdomains (unlikely).