It won't necessarily be the instance name, depending on how the external web server has been set up.
- Log in to post comments
It won't necessarily be the instance name, depending on how the external web server has been set up.
Documentation at https://intersystems-community.github.io/vscode-objectscript/configurat… has now been updated to include this information.
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"
}
},
...
}Please open an issue at https://github.com/intersystems-community/vscode-objectscript/issues
Screenshots can be pasted from clipboard direct into GitHub.
Thanks.
Interesting. Based on doc at https://docs.intersystems.com/healthconnectlatest/csp/documatic/%25CSP… the common attribute of all the faultily-displaying properties is that they are calculated. Does that hold true for the ones not shown in your screenshot?
Turns out it wasn't hard to add this. Download and install 1.8.2-beta.2 if you want to try it out.
.png)
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.
Were you logged in as a user with the %All role when you clicked the update link in WebTerminal?
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:
.png)
Maybe your upgrade procedure went wrong. I suggest you download the XML distribution and import it again.
One way is to use my webterminal-vscode extension in conjunction with the WebTerminal package.
An example is shown in https://community.intersystems.com/post/use-serenji-debug-your-rest-ser…
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
Maybe you need to sign up on the Columnar Storage Early Access Program at https://gs2022.isccloud.io/#early-access
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.
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.
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.
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.
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.
This is probably best handled in the GitHub repository at https://github.com/intersystems-community/webterminal/issues
Are you willing to open a new issue there?
Either way please confirm what URL you are launching WebTerminal at, e.g. http://localhost:57772/terminal/
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.
Marketplace is showing 99 installs already. Thanks for all the interest so far. Will you be number 100?
Alexander, neither of the files you asked for are produced by MSM (Micronetics Standard MUMPS, acquired in 1998 by InterSystems).
Seems to be some confusion about whose (or which) app was first in Community section after the first day:
.png)
Evaluate $USERNAME server-side.
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.
Is the IRIS instance whose log this comes from set up as a member of a mirror?
The name of the security resource associated with the (CACHE|IRIS).DAT file is embedded in the label block in the database itself.
It is still available on Google Groups.
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?
Looks like the same issue as https://github.com/intersystems-community/webterminal/issues/141