1) sometimes the user won't have access to run either cmd or powershell so without logging out and then back in as another user, that's not possible.
2) the commands feature stores my command history, which would grant me immediate access to the previous command i might need to run again.
3) the commands feature also stores a record in the log of exactly what commands were run, and their output which i personally need for auditing purposes.
4) through the use of extensions i can also manipulate commands behavior to effect shortcodes without having to install additional software.
5) the commands feature is already elevated. if i have to open an elevated interactive prompt on a corporate device, for example, then the user can kill my SC task immediately after it's run and will have a persistent elevated shell they can then use to abuse the device or potentially abuse the clients network with.
6) on Win10 an end user without admin rights could just click the eye to see the password i enter when typing in the admin credentials as i am typing it.
7) not every command i run needs to be visible to the client. while some are as simple as dir and del, others will be sc delete or 'secret sauce' that include business logic or advanced functions that could be catastrophic in the hands of an unskilled user that might try to fix it themselves next time.
8) by your logic, there's no reason to include the commands feature in the SC backend interface either, since the tech could always just login to the device, open a cmd prompt or powershell prompt, then run the commands. It's not that the feature is necessary, but that it would make things easier for us. if the goal for the software is to improve the tech experience, this would do that. at least for me.
9) ditto a few of those but replace 'end user' with 'hacker/malware/keylogger/malicious user/person who stole the device' and you'll see a couple more reasons why the user doesn't always need to see the commands (or even know a tech is connected)
the "duplicate" you created is not a duplicate. this ticket requests showing local IP address. my ticket requests the SSID, type of connection, and connection names, in addition to the local IP address. I even provided the code to do some of it.
you can remove it from within the END menu. select "Uninstall and End" which "Combine both options by first uninstalling the client software and then removing the session from the list." I know that this isn't really a solution for rogue IP addresses, but it does attempt to uninstall the software first, so you get the chance of removing it's attempts to connect to your server. blocking at the IP level, while effective, consumes resources on every TCP connection, so should be avoided if possible.
roboform works fine with the SC app
to expand on this, keyboard navigation within the web interface is sorely lacking. i am a true blue keyboarder and SC is one of the few apps I find myself reaching for the mouse *all the time*. I would love to be able to SHIFT+TAB from the Commands box to the device listing, use CTRL+up/down to navigate to the previous/next device, then TAB again to get back to the Commands box. Even CTRL+left/right to hop between interface columns (function, list, devices, properties) would be fantastic.
The "Commands" feature is my favorite of SC which means I rarely need to open an interactive session. but when I *do* have to open a session, I should not have to go back to the browser (or waste time opening powershell or a command prompt) just to run a simple command.
Customer support service by UserEcho