Chromoting: Implemented security attention sequence (SAS) emulation on Windows.

remoting/host/event_executor_win.cc

Index: remoting/host/event_executor_win.cc
diff --git a/remoting/host/event_executor_win.cc b/remoting/host/event_executor_win.cc
index b1f58427f4c01799147294faa6b264b37c15ac0d..724e18c66d002f1ff59229694655606eeca0aa60 100644
--- a/remoting/host/event_executor_win.cc
+++ b/remoting/host/event_executor_win.cc
@@ -9,10 +9,14 @@
 #include "base/bind.h"
 #include "base/compiler_specific.h"
 #include "base/message_loop.h"
+#include "ipc/ipc_channel.h"
+#include "ipc/ipc_channel_proxy.h"
 #include "remoting/host/capturer.h"
 #include "remoting/proto/event.pb.h"
 #include "ui/base/keycodes/keyboard_codes.h"
 
+#include "remoting/host/chromoting_service_messages.h"
+
 namespace remoting {
 
 using protocol::MouseEvent;
@@ -20,15 +24,23 @@ using protocol::KeyEvent;
 
 namespace {
 
+// Name of the chromoting service IPC channel.
+const char kChromotingServiceChannelName[] = "chromoting_service";
+
 // A class to generate events on Windows.
-class EventExecutorWin : public EventExecutor {
+class EventExecutorWin : public EventExecutor, public IPC::Channel::Listener {
  public:
-  EventExecutorWin(MessageLoop* message_loop, Capturer* capturer);
+  EventExecutorWin(MessageLoop* message_loop,
+                   base::MessageLoopProxy* io_message_loop,
+                   Capturer* capturer);

[Wez, 2012/03/07 01:56:13]

EventExecutorWin is responsible just for injecting the events; the SendSAS and
desktop-switching features feel like they belong in a separate
EventExecutorServiceWin class that would call on to EventExecutorWin to do the
actual injection after handling the service-specific work?

[alexeypa (please no reviews), 2012/03/07 19:59:08]

There is DesktopEnvironment class that looks like a better choice for hosting
the IPC channel.
It will give a reference to the channel to the executor and capturer. The
executor will use the channel to inject SAS. I think it is aligned with the
purpose of the executor perfectly. After all it is just another even to inject.
Once the captures will be moved out to a separate component it will use the IPC
channel to talk to encoder. 

[Wez, 2012/03/08 00:01:33]

DesktopEnvironment is a cross-platform interface for exposing the cross-platform
interfaces to the platform-specific integration implementations to the
ChromotingHost, so it shouldn't know anything about the IPC channel.

The EventExecutorWin is designed just to inject input events; it's used in IT2Me
and so should not have any knowledge of issues specific to running in the
context of a service.

You're right that it's just another event to inject - this is why I suggested
having an EventExecutorServiceWin that takes care of the service-specific work,
i.e. IPC and desktop switching, and uses an EventExecutorWin to do normal key
event injection.  EventExecutorServiceWin would expose the same InputStub
interface.

[alexeypa (please no reviews), 2012/03/08 01:52:54]

OK, makes sense.

   virtual ~EventExecutorWin() {}
 
   virtual void InjectKeyEvent(const KeyEvent& event) OVERRIDE;
   virtual void InjectMouseEvent(const MouseEvent& event) OVERRIDE;
 
+  // IPC::Channel::Listener implementation.
+  virtual bool OnMessageReceived(const IPC::Message& message) OVERRIDE;
+
  private:
   void HandleKey(const KeyEvent& event);
   void HandleMouse(const MouseEvent& event);
@@ -36,13 +48,28 @@ class EventExecutorWin : public EventExecutor {
   MessageLoop* message_loop_;
   Capturer* capturer_;
 
+  // IPC channel connecting the host with the chromoting service.
+  scoped_ptr<IPC::ChannelProxy> chromoting_service_;
+
+  bool scroll_pressed_;
+
   DISALLOW_COPY_AND_ASSIGN(EventExecutorWin);
 };
 
 EventExecutorWin::EventExecutorWin(MessageLoop* message_loop,
+                                   base::MessageLoopProxy* io_message_loop,
                                    Capturer* capturer)
     : message_loop_(message_loop),
-      capturer_(capturer) {
+      capturer_(capturer),
+      scroll_pressed_(false) {
+  // Connect to the service.
+  if (io_message_loop) {
+    chromoting_service_.reset(new IPC::ChannelProxy(
+                                      kChromotingServiceChannelName,
+                                      IPC::Channel::MODE_CLIENT,
+                                      this,
+                                      io_message_loop));
+  }
 }
 
 void EventExecutorWin::InjectKeyEvent(const KeyEvent& event) {
@@ -54,6 +81,22 @@ void EventExecutorWin::InjectKeyEvent(const KeyEvent& event) {
     return;
   }
 
+  // Poor man's Ctrl+Alt+Delete emulation: a double Scroll Lock is converted to
+  // the security attention sequence.
+  // TODO(alexeypa): replace this with proper SAS handling.
+  if (chromoting_service_.get() != NULL && event.keycode() == VK_SCROLL) {
+    if (event.pressed()) {
+      if (scroll_pressed_) {
+        chromoting_service_->Send(new ChromotingServiceMsg_SendSas());
+        scroll_pressed_ = false;
+      } else {
+        scroll_pressed_ = true;
+      }
+    }
+  } else {
+    scroll_pressed_ = false;
+  }
+
   HandleKey(event);
 }
 
@@ -165,11 +208,16 @@ void EventExecutorWin::HandleMouse(const MouseEvent& event) {
   }
 }
 
+bool EventExecutorWin::OnMessageReceived(const IPC::Message& message) {
+  return false;
+}
+
 }  // namespace
 
 EventExecutor* EventExecutor::Create(MessageLoop* message_loop,
+                                     base::MessageLoopProxy* io_message_loop,
                                      Capturer* capturer) {
-  return new EventExecutorWin(message_loop, capturer);
+  return new EventExecutorWin(message_loop, io_message_loop, capturer);
 }
 
 }  // namespace remoting