go to post John Murray · Jul 11, 2022 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.
go to post John Murray · Jul 11, 2022 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.
go to post John Murray · Jul 11, 2022 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.
go to post John Murray · Jul 7, 2022 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.
go to post John Murray · Jul 4, 2022 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.
go to post John Murray · Jul 4, 2022 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/
go to post John Murray · Jul 3, 2022 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.
go to post John Murray · Jun 30, 2022 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.
go to post John Murray · Jun 22, 2022 Marketplace is showing 99 installs already. Thanks for all the interest so far. Will you be number 100?
go to post John Murray · Jun 21, 2022 Alexander, neither of the files you asked for are produced by MSM (Micronetics Standard MUMPS, acquired in 1998 by InterSystems).
go to post John Murray · Jun 1, 2022 Seems to be some confusion about whose (or which) app was first in Community section after the first day:
go to post John Murray · May 23, 2022 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.
go to post John Murray · May 18, 2022 Is this the place to start? https://openexchange.intersystems.com/package/iris-google-run-deploy-tem...
go to post John Murray · May 11, 2022 Is the IRIS instance whose log this comes from set up as a member of a mirror?
go to post John Murray · May 5, 2022 The name of the security resource associated with the (CACHE|IRIS).DAT file is embedded in the label block in the database itself.
go to post John Murray · Apr 28, 2022 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?
go to post John Murray · Apr 27, 2022 Looks like the same issue as https://github.com/intersystems-community/webterminal/issues/141
