When running “logmein” command in WebUI spawned terminal, the QR shows up, but there is not timeout, APP reads it as login QR but does not move forward with confirmation. Terminal is locked on displaying QR until I press Ctrl+C which terminates it, or terminal times-out. Same behavior is displayed whether I am logged in in WebUI or not. On “whoami” command, terminal always displays “AnonXXXX”.
I went ahead and had the functionality of check-lists integrated into our forums.
@PauliX kindly contact Mike for some of the details.
I spoke with Mike already.
As of now to use lists we need to type ‘[ ]’ i.e two consecutive square brackets to have a modifiable check-box pop into place. So let me restructure the reported things right over here:
not timeout when using “logmein” from terminal in UI
check out the behaviour after the QR gets scanned by the mobile app
“whoami” always shows “AnonXXXX”
I will be back with more.
1 Like
there used to be a timeout, of course, equal to 180 seconds i.e. 3 minutes.
The timer was not being shown though.
I have commented out the line 9392 preventing it from being shown in terminals launched from the UI, anyone knows why that was used to be the case? Seems like it was ‘by-design’.
After further investigation I can confirmed that it might had been the case that the process would not time out at all. I won’t be confirming this and proceed with making sure it works, instead.
Seems like I’ve nailed this part.
Remember that one can use CTRL+Z to kill any process.
In addition, I have proceeded with verifying the results of having a QR Intent scanned, when executing ‘logmein’ from within of the Terminal UI dApp.
It turned out the routing sub-system has been having troubles with delivering response from mobile app down to the very instance of the terminal.
As you might know, we employ a very sophisticated, hybrid routing apparatus. Meaning endpoints of a variety of types are included within of the very same routing table on same node.
Currently the ‘logmein’ utility was using routing against ‘terminals’, I have altered this.
Now ‘logmein’ generates QR Intents, the response to which, are to be routed to a particular instance of a Decentralized Processing Thread.
Terminal based routing I have created a separate ticket.
We have a sub-team working on integration of the internal ticketing system with these ‘forums’.
I am proceeding with further verifications.
and indeed. I am diving into this topic.
it is fixed now.
Note that logging in from within of the scope of the Terminal UI dApp would affect the context of the app only. It would not affect any outside scope.
Further research and discussion is needed as of whether it would be beneficial for the end-user to have LogMeIn affect the scope of the entire UI (which of course is very feasible to do).
We just might introduce a default behaviour and another one selected through optional parameters, Thread’s user-mode flags etc.
I am releasing this to production. Mike is available so the update should come through in less than an hour.
I suppose.
We support showing QR Intents in terminal through UNICODE-half, and through the WebGL rendered full screen QR codes, as you know.
Now, I guess the conditional branch was on the WebGL mode, so that the code would not be displaying the text-based count-down.
Do note that as far as I recall, the mode can be set by user through one of the user-mode available flags (from Terminal).
I assumed that when you log in into WebUI, you are sort of “automatically” logged in when you run terminal sessions, and sort of locked as a logged user. I think that you should not be able to have a terminal session logged in as someone different than WebUI session. No point in it, apart from some malicious intent.
You are. Once fire up the Desktop environment, it is when the initial Log-Me-In QR code is shown through WebGL.
Once that very code is scanned, the mobile app initiates an onion routed connection, across the full-node which is serving you the WebUI, towards your very web-browser.
The User-Session data structure is processed by VM Context (running within the web-browser).
The VM Context notifies all the running applications (that have signed up for an appropriate event) that the user has just logged on. New instances of UI dApps may check the identity of the currently logged-on user at any time.
For instance, the Terminal UI dApp, once it bootstraps, it verifies the identity of the currently logged-on user, goes into the scope of his home directory autonomously upon its launch. Same with say the File Manager UI dApp.
I think that you should not be able to have a terminal session logged in as someone different than WebUI session. No point in it, apart from some malicious intent.
Point taken. Still, taking Linux operating system as an example, or even Microsoft Windows, there the concept of ‘impersonation’ is quite proliferated. The ‘runas’ command. We definitely need to reconsider and look more at these grounds, as the functionality has been implemented on a rather ad-hoc basis. Everything holds, but we definitely might want to rethink it.
We might allow ourselves being just a bit lazy about that as in the end, everything is secure as long as code-processing by nodes as full-redundancy is secure.