Closed gjsjohnmurray closed 3 months ago
@gjsjohnmurray I think we should remove the token entirely and have the browser handle the auth. We need this token for source control web pages because they're launched in an iframe. Do we really need to log people in if their web browser may already have a cookie that works? There's already a context switch to a separate application so I don't think that requiring a log in is hat much more jarring.
cc @isc-rsingh
Their browser will only have a working cookie if they have already run a template/add-in of the same type during this browser session. By "same type" I mean built-in (/isc/studio/templates) vs user-supplied (/isc/studio/usertemplates). I think we should be trying to make the feeling of integration between different components better rather than worse.
In the Yuzinji case the user will actually need to authenticate twice when running the add-in for the first time in their external browser session. This is because, for sound architectural reasons, the add-in starts as a /isc/studio/usertemplates page and then redirects (client-side) to a /csp/yuzinji app.
The add-in also currently uses in its /csp/yuzinji pages some %session.Data that gets created in its /isc/studio/usertemplates pages. We could re-engineer that if necessary.
@gjsjohnmurray I'm going to consult with our security team to make sure this use of CSPSHARE doesn't present a significant risk before I officially review the change.
The Studio add-in that is integral to George James Software's Yuzinji tool misbehaves when invoked from VS Code.
This PR corrects the issue by adding CSPSHARE=1 to the URL with which an add-in is launched.
Based on commit https://github.com/intersystems-community/vscode-objectscript/pull/756/commits/f58416c6719b0f75bede71ed58240227bf8160f2 by @timleavitt which was part of PR #756 I think it's very likely Studio adds this parameter too, which would explain the problem which this PR fixes.