All
Accepted answers
John Murray · Jul 19, 2022 go to post

The Serenji VS Code extension from George James Software supports direct backend debugging of REST endpoints in Caché and InterSystems IRIS.

The debugging features of Serenji require an activation key. We provide free 30-day keys upon request.

John Murray
Senior Product Engineer
George James Software

John Murray · Jul 11, 2022 go to post

Instead of adding the %All role to the /terminalsocket web app I suggest you add %DB_IRISLIB which should be sufficient to solve your issue.

My guess is, this environment used to give public %DB_IRISLIB:R but then someone tightened security by removing this, around the time you upgraded WebTerminal.

Such a change ought to show up in the audit log.

John Murray · Jul 11, 2022 go to post

UnknownUser is normal for the /terminalsocket session.

Does the problem also occur if you start from an incognito/InPrivate instance of your web browser?

Previously you reported that WebTerminal is working OK on another of your InterSystems environments. Is this still the case? Is that one using 4.9.5 yet?

For the one that fails to make the websocket connection I suggest you use F12 in your browser to open Developer Tools, and make sure network tracing is active before you go to the /terminal/ URL to open a WebTerminal. Look at the network trace messages, and compare them to equivalent messages from a different web browser session that connects successfully to WebTerminal on your other environment.

I'm not clear whether WebTerminal ever worked on this InterSystems instance, e.g. with WebTerminal 4.9.3.

Maybe also worth checking what the InterSystems security audit log is showing around the time you fail to connect with WebTerminal. You may need to turn this auditing on, and perhaps enable it for some additional event types.

John Murray · Jul 11, 2022 go to post

As long as the XML import compiled the classes, there's nothing else you need to do in order to benefit from the update.

I suggest you stop using WebTerminal for at least 15 minutes, then check in Portal's Web Sessions page (under System Operation) that no /terminalsocket sessions remain.

Next, launch a WebTerminal. Confirm it reports being version 4.9.5. Check that the Web Sessions page shows one /terminalsocket entry. Now close your WebTerminal browser. Refresh the Web Sessions page. The /terminalsocket entry should no longer be there.

John Murray · Jul 7, 2022 go to post

WebTerminal 4.9.5 is now available. After updating to this you should no longer see /terminalsocket web sessions hanging around for 15 minutes after WebTerminal browser windows have been closed.

This should help with license starvation issues.

John Murray · Jul 4, 2022 go to post

When comparing between an environment that works and the one that doesn't, did you also check the settings of the /terminalsocket application? If not, please do that.

John Murray · Jul 3, 2022 go to post

WebTerminal 4.9.4 containing this fix has now been released. Unless you have disabled automatic updates you should be offered the new version when you next use WebTerminal. Alternatively download the XML and import it.

John Murray · Jun 30, 2022 go to post

I have submitted a PR and hope that the WebTerminal project owner will review and merge it soon. Meanwhile if you want to jump the gun you can download the updated XML file from the PR.

John Murray · Jun 21, 2022 go to post

Alexander, neither of the files you asked for are produced by MSM (Micronetics Standard MUMPS, acquired in 1998 by InterSystems).

John Murray · Jun 1, 2022 go to post

Seems to be some confusion about whose (or which) app was first in Community section after the first day:

John Murray · May 23, 2022 go to post

I suggest you include a widget on every page you serve, and make the widget use client-side JS to display a countdown which updates every second. Set its initial value from %session.AppTimeout.

John Murray · May 11, 2022 go to post

Is the IRIS instance whose log this comes from set up as a member of a mirror?

John Murray · May 5, 2022 go to post

The name of the security resource associated with the (CACHE|IRIS).DAT file is embedded in the label block in the database itself.

John Murray · Apr 28, 2022 go to post

IRIS doesn't bundle its own ssh server. Unless your host platform offers ssh (not common on Windows) there'll be nothing for your ssh client to connect to.

For IRIS on Windows you have the option of enabling the %Service_Telnet service and connecting using telnet rather than ssh. You can optionally add extra security to this by configuring it to use TLS.

But as you're talking about localhost why not simply launch Terminal off your IRIS launcher in you Windows System Tray?

John Murray · Apr 6, 2022 go to post

Hmm, looks like the code gets that setting from the "objectscript" settings object. So please try this in your JSON:

"objectscript.http.proxyStrictSSL": false

Ignore the hover about it being an unknown setting.

John Murray · Apr 6, 2022 go to post

Does it make a difference if you add this setting?

"http.proxyStrictSSL": false
John Murray · Mar 17, 2022 go to post

Studio connects to the superserver port (tcp 1972) using a proprietary protocol but the VS Code extension uses REST APIs over http(s), typically to the same web server as you use when accessing InterSystems Portal. So if your Portal URI contains :57772 then you should specify 57772 as the port in VS Code's connection spec.