On 01/12/2010 03:28 PM, Luiz Capitulino wrote: > On Mon, 11 Jan 2010 13:55:19 +0000 > "Daniel P. Berrange" 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 |