Corrected support for TightVNC extensions - always sending authentication capability...

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

diff --git a/common/rfb/SConnection.cxx b/common/rfb/SConnection.cxx
index deaa96684999b4db2ba427ac50afbeb6962e865c..130170f2187b18e64ce4c4a3a75ac4f1f501b4ba 100644 (file)
--- a/common/rfb/SConnection.cxx
+++ b/common/rfb/SConnection.cxx
@@ -253,23 +253,18 @@ void SConnection::offerAuthentication()
   if (caps.getSize() < 1)
     throwConnFailedException("No supported security types");
 
-  // FIXME: We should never send an empty capability list if we are prompting
-  //        local user to accept client connections. And if we do send an
-  //        empty list, then we cannot send a "security result".
-  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.
-    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;
-  }
+  // 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;
 }
 
 void SConnection::processAuthTypeMsg()