We recently realized Ignition perspective administrative web page (same with any Ignition project but for simplicity we will say the admin page) cannot be loaded in Firefox in incognito mode.
To be more precise the website in question after 5 or more minutes is able to open in Firefox in incognito mode but it takes so many minutes we can say for all practical purposes it is not.
We tried to debug with curl to be as browser agnostic as possible and realized that Ignition makes heavy use of HTTP 302 redirects to the point that even following the redirects ends in an endless cycle (we talk about 50 or more redirects), for instance:
we have another Ignition installation (slightly different version number) which has the same 302 endless redirects problem with curl but can be opened in Firefox in incognito almost instantly.
Can someone tell us what is going on? it is hard enough to debug Ignition applications as they are, but without the assurance of at least having a working incognito mode the problem is amplified ten fold because we don't know what is cached and what is not.
We previously used Chrome but some things are rendered differently in Firefox and we now have to debug both in Chrome and Firefox (potentially Edge as well).
anyway we don't have any middleware: we have windows machines with ignition installed on AWS EC2, nothing in between.
I checked through company connection and via an hotspot on my phone, same behaviour.
I also checked it wasn't due to the fact we were using the IDP which could potentially make weird redirects but my localhost installation has no IDP enabled (it uses the default ignition authentication IDP).
So, it appears that we constantly redirect you if you don't provide us with a (valid) JSESSIONID cookie. You can e.g. tell curl to store one with the -c flag - so:
❯ curl -L 'http://localhost:8088/'
curl: (47) Maximum (50) redirects followed
I don't know enough about curl to know if there's a way to recycle cookies across redirects without requiring an actual file for storage.
My guess is your Firefox private session is set to a stricter mode that doesn't accept any cookies, even to store temporarily while the session is open, and that's why you get into a redirect loop. My Firefox, even in private mode, is able to connect to localhost:8088 just fine, so that might be a setting you can configure.
This is possibly a bug (I don't really know the internal mechanisms well enough to judge confidently) but even if it we do treat it as such, it'll be some time before we can issue a fix, so you may as well try to work around it.
Ok, notice the firefox I have is the latest (120.0.1 64-bit) and I just installed it from scratch just to be sure no weird configurations are present.
So people might experience this behaviour with any Firefox 120.0.1 browser in incognito mode and future releases.
Thank you for your time.