John Murray · Aug 24, 2022 go to post

It won't necessarily be the instance name, depending on how the external web server has been set up.

John Murray · Aug 24, 2022 go to post

In the intersystems.servers object in your settings JSON you can add a pathPrefix property within the webServer object of your connection definition. In your example:

"intersystems.servers": {
...
    "server1": {
        "webServer": {
            "host": "localhost",
            "port": 443,
            "scheme": "https",
            "pathPrefix": "/instance1"
        }
    },
...
}
John Murray · Jul 28, 2022 go to post

Turns out it wasn't hard to add this. Download and install 1.8.2-beta.2 if you want to try it out.

Only the editable file gets coloured, not the preview. It may be possible to address that, but would require more work than I have time for at the moment.

John Murray · Jul 25, 2022 go to post

Were you logged in as a user with the %All role when you clicked the update link in WebTerminal?

John Murray · Jul 21, 2022 go to post

I haven't seen this problem.

The GitHub source of this method doesn't seem to check the status of its ParseStream call before trying to read the stream:

Maybe your upgrade procedure went wrong. I suggest you download the XML distribution and import it again.

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?