Set-cookie blocked in non-https test environment web browser for REST API.
Hey,
I'm testing a REST API that is used for our IRIS Backend with a mobile app (Angular / ionic).
The problem is that, our test environment does not yet have HTTPS capabilities, it's something we're going to set up ASAP, but right now we don't have it set up.
We want to test the API endpoints via a web browser using either a test application built in Angular, or the app itself built with NPM via the browser. This means that the set-cookie headers are being blocked by the browser.
Is there a way that we can allow the set-cookie header to be set in the browser for testing?
It's also worth noting that if I test with a browser on my localhost, then the endpoints work as intended, but if I test using our remote test server, they do not, which is why I've tried adding CORS headers etc, but nothing seems to work so far.
The requests also work as intended via Postman always.
My suspicion is that the issue is relating to javascript being blocked from accessing the HTTP headers: Set-Cookie - HTTP | MDN (mozilla.org) but I am out of ideas currently.
Things I've tried so far;
- Manually adding same-site ="none" and removing checks requiring HTTPS if same-site="none" in %CSP.Response
- Manually adding CORS headers to the writehttpcookie method in %CSP.Response
- Ensuring withcredentials is setup on the frontend requests
Any help would be greatly appreciated,
Thanks
Comments
What you are seeing is consistent with browser cookie policy rather than an IRIS header-access issue. InterSystems IRIS lets you control cookie behavior for the web application, including whether cookies are used for session management and the default SameSite handling, but the documentation explicitly states that when SameSite=None is used for cross-site requests, browsers may require HTTPS. [1][2][3][4]
For your IRIS web application, the relevant settings are under the application’s Session Settings:
- Use Cookie for Session controls whether session tracking uses cookies, with options Always, Never, or Autodetect. [1]
- Session Cookie Scope controls the default
SameSitevalue for session, login, CSRF, and Group ID cookies. [1] - User Cookie Scope controls the default
SameSitevalue for user-defined cookies created with%CSP.Response.SetCookie. [1]
If your Angular/Ionic app running in the browser is making a cross-site request to the IRIS server, then using SameSite=None is the setting associated with allowing cookies on cross-site requests. But the documentation says browsers may require HTTPS for that case, so there is not a documented IRIS-side way to make browsers accept that cookie over non-HTTPS remote access. [1][2][3][4]
Your localhost behavior versus remote test server behavior also fits that distinction: the issue is not that JavaScript cannot read Set-Cookie, but that the browser may refuse to store/send the cookie under cross-site, non-HTTPS conditions. Postman working does not contradict this, because the cited IRIS documentation here is specifically about browser session/cookie behavior for web applications. [1][2][3][4]
Important: To use these settings, you must first set the UseSession parameter of the application’s dispatch class to a non-zero value; otherwise, changes in the value of any of these settings have no effect. For more information, see Creating a REST Service Manually. [1]
The one documented workaround within IRIS session configuration is to avoid cookies entirely for session tracking by setting Use Cookie for Session to Never, which switches session management to URL rewriting instead of cookies. Whether that is practical for your REST/browser flow is not described in the retrieved material, so I cannot say more than that. [1]
So the direct answer is: there is no documented way in the retrieved IRIS material to force a browser to accept a cross-site Set-Cookie on a non-HTTPS remote environment. The documented guidance indicates that for SameSite=None, browsers may require HTTPS, so enabling HTTPS is the supported path. [1][2][3][4]
Sources: