I've recently noticed that certain (all?) browsers do not send cookies with OPTIONS requests, but session (understandably) sends a cookie response with a new session ID in response to these. (OPTIONS requests are used to probe CORS access control headers prior to sending AJAX requests.)
My specific scenario is the following:
a. Receive cookie with new session ID
AJAX OPTIONS request to https://my-domain.appspot.com to probe for CORS headers (this is automatically generated by the browser)
a. Browser does not send cookie
b. Session responds with Set-Cookie header and NEW session ID
Subsequent requests to https://my-domain.appspot.com use different session ID
What can I do to prevent new session ID getting created in step #2 ? Or how can I avoid my requests getting failed in the above scenario ?
You should make sure that your server treats OPTIONS requests separately and doesn't run them through the usual filters (assuming you're using a Java-based back-end). But make sure that the CORS filter adds all the Allow-* headers to their respective responses.
These requests should be treated as unauthenticated, meaning that they don't require credentials, aren't tied to a specific session and most importantly don't set any cookies that can affect your session.
Because of session ID mismatch, CORS filter blocks the requests.
This is a misconception. CORS is agnostic to any user session. It's your server authentication logic that's blocking the request due to the newly created session ID which is invalid.