Reverted the changes appeared in revisions 2173,2181. We better always send the "security result" message in the protocol version 3.8, even after an empty list of authentication capabilities.

git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@2189 3789f03b-4d11-0410-bbf8-ca57d06f2519

1 files changed, 16 insertions, 12 deletions

diff --git a/common/rfb/SConnection.cxx b/common/rfb/SConnection.cxx
index 130170f2..9e47900e 100644
--- a/common/rfb/SConnection.cxx
+++ b/common/rfb/SConnection.cxx
@@ -253,18 +253,22 @@ void SConnection::offerAuthentication()
   if (caps.getSize() < 1)
     throwConnFailedException("No supported security types");
 
-  // FIXME: We could send an empty capability list if we do not require
-  //        authentication and any local user interaction. But the problem
-  //        is that this class does not know if local user will be prompted
-  //        to accept/reject connection.
-  //        Thus, currently we always send non-empty capability lists,
-  //        although this is not compatible with certain TightVNC viewers
-  //        that do not understand authentication type "AuthNone" and expect
-  //        an empty capability list for no authentication.
-  os->writeU32(caps.getSize());
-  caps.write(os);
-  os->flush();
-  state_ = RFBSTATE_TIGHT_AUTH_TYPE;
+  if (caps.includesOnly(secTypeNone)) {
+    // Special case - if caps includes nothing else than secTypeNone, we send
+    // an empty capability list and do not expect security type selection from
+    // the client. Then, continue the protocol like if the client has selected
+    // secTypeNone (starting at base protocol version 3.8, "security result"
+    // will follow).
+    os->writeU32(0);
+    os->flush();
+    processSecurityType(secTypeNone);
+  } else {
+    // Normal case - sending the list of authentication capabilities.
+    os->writeU32(caps.getSize());
+    caps.write(os);
+    os->flush();
+    state_ = RFBSTATE_TIGHT_AUTH_TYPE;
+  }
 }
 
 void SConnection::processAuthTypeMsg()