Hi Mike,
with the "easy change" and watching the 2 log files, it would be possible to
see, which user is currently online, which session he uses and accounting of
all sessions for the users. I also got the connection to the pid of the guacd
process, so i can kill his session. All that without using the Admin-Account.
That would be great. I don't think that we need the protocol changes, the only
benefit, i currently see, that all informations would be in 1 Log-File and not
in 2. What do you think about it ?
So could you please integrate the "easy changes", and the logging of the
identifier
for each connection-specific message, that would be great.
The "easy changes" has to be in the client, right ?
One thing left in my mind. If a user has connected to jetty/tomcat with his
credentials, but has not start a session yet, how can i kick it off. I try
to set the disable flag in the db, but that only affect's new login tries
not the current login. Maybe you also know a solution for that.
best regards
Michael
Am 23.12.2017 um 21:40 schrieb Mike Jumper:
On Fri, Dec 22, 2017 at 3:51 PM, mniehren <[email protected]
<mailto:[email protected]>> wrote:
Hi Erik,
i tried out jetty and tomcat but in the log of both, i found the real
username
and the connection name, not more .
In the guacd.log i only have the encrypted ones.
guacd has no concept of user accounts. The values you're seeing in guacd's logs are not encrypted
usernames, but unique identifiers generated upon connecting to identify the current connection
(such that it can be joined) and to identify the logical user accessing that connection (to
distinguish them from other usages of the same connection).
Is there a possiblity that either jetty/tomcat logs the encrypted username
or the pid of the guacd-process which handles the connection or that
guacd logs the real username and/or connection name ?
Logging the unique identifier of the guacd connection would be an easy change, and would allow
some degree of correlation there. Though guacd already logs the connection identifier once per
connection, logging it for each connection-specific message would probably be a good idea, as well.
Exposing the unique identifier of the logical user would require protocol and API changes, but may
be reasonable.
Providing some means for the webapp to assign an arbitrary informational tag to be included in log
messages (like the username and unique value to allow things to be correlated on a 1-to-1 basis)
might also be reasonable, but would also require protocol and API changes.
- Mike
--
Michael Niehren __ _ powered by
/ / (_)__ __ ____ __
/ /__/ / _ \/ // /\ \/ /
/____/_/_//_/\_,_/ /_/\_\
