On 01/12/2010 03:28 PM, Luiz Capitulino wrote:
On Mon, 11 Jan 2010 13:55:19 +0000
"Daniel P. Berrange" <address@hidden> wrote:
So perhaps we should declare that the lifecycle is
- CONNECT (provide IP / port details)
- AUTHENTICATED (provide IP / port details + authenticated ID details
eg x509 dname, or SASL usernsmae)
- DISCONNECT (provide IP / port details)
Obviously AUTHENTICATED may be optional if the client goes away
immedaitely before trying auth. The AUTHENTICATED event probably
also ought to allow for an indication of success vs failure so
the app can see failed login attempts
I'm having an issue with the reporting of failure.
Turns out we can have a few error conditions on login and they are
auth mechanism dependent. Also, as I'm not familiar with the code,
it's not always easy to get the ID information on failures.
So, what is simple to do is to have an event called VNC_AUTHENTICATION,
it will have a 'authenticated' key which can be true or false. If it's true
authentication has been successful and ID information is available,
otherwise authentication has failed and only IP/port info is available.
Of course that CONNECT and DISCONNECT events are also provided.
It might be worthwhile looking at the events that gtk-vnc supports.
VNC_CONNECTED, <- client has connected
VNC_INITIALIZED, <- initialized is completed
VNC_DISCONNECTED, <- client has disconnected
VNC_AUTH_FAILURE, <- authorization has failed
VNC_AUTH_UNSUPPORTED, <- authorization has failed (could not negotiate an auth type)
Initialized can provide you all of the credential information. I think it's stronger than AUTHENTICATED because authentication alone does not imply that a session is active. Initialized tells a listener that at the moment this is received, the VNC session is active. If I'm a management tool, that's the thing I'm likely interested in.
Regards,
Anthony Liguori
|