Unable to open DTL/BPL editor in Studio after opening Git UI with IRIS 2024.1

[raymond-rebbeck]

After upgrading from IRIS for Health 2023.1 to 2024.1 have observed the following behaviour: after starting Studio, the DTL/BPL editor is able to be opened without issue, however after opening the 'Git UI' screen (can just open and immediately close the window), it is no longer possible to successfully open the DTL/BPL editor and an error is observed, see the attached screenshot:

In 2024.1 the error only occurs after the Git UI is open, the Git Settings page is able to be opened and has no apparent negative effect on the DTL/BPL editor. When Studio is in this state changing the namespace and then back again restores the ability to open the DTL/BPL editor, until after the next time Git UI is opened. Sometimes I am given a login prompt and receive the error in the screenshot after logging in.

I have tried other versions: IRIS 2023.1 and 2023.2 have no apparent issue at all. IRIS 2023.3 seems unable to successfully open the DTL/BPL editor at all, regardless of whether Git UI is opened or not, with the same error as in the screenshot.

This occurs with git-source-control 2.3.1 and 2.4.0, have not tried other versions.

Summary of versions I have looked at:
No problem at all:
IRIS for UNIX (Ubuntu Server LTS for x86-64 Containers) 2023.1.1 (Build 380U) Fri Jul 7 2023 23:38:49 EDT [Health:5.1.0-1.m1]
IRIS for UNIX (Ubuntu Server LTS for x86-64 Containers) 2023.2 (Build 227U) Mon Jul 31 2023 18:06:14 EDT [Health:5.1.3]

Cannot open any DTL/BPL at all, regardless of Git UI or changing namespace:
IRIS for UNIX (Ubuntu Server LTS for x86-64 Containers) 2023.3 (Build 254U) Wed Nov 8 2023 12:55:49 EST [Health:7.0.3]

Can open DTL/BPL but not after opening Git UI, does work after changing namespace (until next open of Git UI):
IRIS for UNIX (Ubuntu Server LTS for x86-64 Containers) 2024.1 (Build 267_2U) Tue Apr 30 2024 16:04:37 EDT [Health:7.2.0-1.r1]

[raymond-rebbeck]

Just to provide some additional information, clicking 'Reload' does nothing useful the error occurs repeatedly with no observed difference, clicking 'Continue' (more than once is required) will close the error dialogue but the DTL/BPL editor is not properly loaded and not usable.

[isc-tleavitt]

@raymond-rebbeck thank you for all of the detail here. It's good to know that the behavior in 2.3.1 and 2.4.0 of git-source-control is the same. I strongly suspect this is an upstream issue in IRIS since it's upgrade-related, but hopefully we'll be able to find some remediation in git-source-control itself.

@isc-pbarton could you dig into this a bit and loop in WRC if needed?

[isc-tleavitt]

@isc-pbarton of relevance here are DP-421886 (caused the issue first present in 2023.3) and DP-428566 (fixes the "can't open BPL/DTL at all" issue in 2024.1 but apparently doesn't play well with our use of CSPCHD in git-source-control) - I think we'll need to dig into DP-428566 and figure out how to leverage it.

[isc-tleavitt]

@isc-pbarton sorry if you already spent time on this - it was bugging me and I ended up continuing the chase. Will have a PR up shortly.

[isc-tleavitt]

Summary on the issue here: Studio constructs a CSP session for shared use between embedded interoperability editors and extensions. The session is not tied to any particular cookie path and is set to autodetect cookie use (rather than always use them). Studio doesn't want to use cookies, but the extension will, so it ends up messing with the session to say "always use cookies, and here's my cookie path" which means the editor can't use the session because the cookie path is different (and for that matter it doesn't seem to be providing cookies).

This behavior is triggered by the extension page making multiple requests, where the second request includes the cookie and thereby steals the session.

The solution, hacky though it is, is to clear out the cookie path and tell the session to go back to autodetecting cookie use after every request to settings and/or the web UI.

[isc-tleavitt]

@raymond-rebbeck we're planning on a 2.4.1 release with a few other bugfixes within the next two weeks; this fix and your recent PR will be included.

[raymond-rebbeck]

I am impressed by the quick turnaround on this, thank you. I have applied the PR fix locally and it has been working fine for me all day.