Handle Security Key requests from outside the remoted session correctly

Handle Security Key requests from outside the remoted session correctly

The recent Mojo conversion changed the communication pattern between the
IPC Server and Client classes used for remote security key message
forwarding.  This change has caused a regression in the scenario where
the security key request originates from outside the remoted session.
The desired behavior is to pass a message to the local SK handler so
it can route/handle the request.  Due to the change in the following
CL, we would instead report that the remote client would handle it,
then return a failure when they sent the request:
https://codereview.chromium.org/2478443002/

The reason for this change is that the session detection logic was wrapped
in the OnChannelConnected() method.  Because you cannot close an IPC channel
from within that method, we would defer the close operation.  With the old
architecture, the client would be waiting for a specific IPC message to
complete the connection (and signal success) but instead would receive
the deferred close/error message and pass on the right message to the local
handler.  This behavior was changed such that the client would now signal
success in its own 'OnChannelConnected()' and then receive the deferred
error.

In order to make this scenario more robust, I have added specific success
and failure IPC messages to be passed to the client from the server and
will use that when establishing the connection.  I've also separated out
the concept of an invalid session vs. and actual connection error so the
IPC client class can provide more accurate details to the local handler.

BUG=674236
Review-Url: https://codereview.chromium.org/2575963002
Cr-Commit-Position: refs/heads/master@{#439685}
(cherry picked from commit afdd0e9701d38723cb5ebae11e4e26a7c19e3d58)

Committed: https://chromium.googlesource.com/chromium/src/+/b9c016474def2fac457b08c42b63a4d09cf5c9f8

[joedow, 2016-12-21 16:23:59]

Description was changed from

==========
Handle Security Key requests from outside the remoted session correctly

The recent Mojo conversion changed the communication pattern between the
IPC Server and Client classes used for remote security key message
forwarding.  This change has caused a regression in the scenario where
the security key request originates from outside the remoted session.
The desired behavior is to pass a message to the local SK handler so
it can route/handle the request.  Due to the change in the following
CL, we would instead report that the remote client would handle it,
then return a failure when they sent the request:
https://codereview.chromium.org/2478443002/

The reason for this change is that the session detection logic was wrapped
in the OnChannelConnected() method.  Because you cannot close an IPC channel
from within that method, we would defer the close operation.  With the old
architecture, the client would be waiting for a specific IPC message to
complete the connection (and signal success) but instead would receive
the deferred close/error message and pass on the right message to the local
handler.  This behavior was changed such that the client would now signal
success in its own 'OnChannelConnected()' and then receive the deferred
error.

In order to make this scenario more robust, I have added specific success
and failure IPC messages to be passed to the client from the server and
will use that when establishing the connection.  I've also separated out
the concept of an invalid session vs. and actual connection error so the
IPC client class can provide more accurate details to the local handler.

BUG=674236

Review-Url: https://codereview.chromium.org/2575963002
Cr-Commit-Position: refs/heads/master@{#439685}
(cherry picked from commit afdd0e9701d38723cb5ebae11e4e26a7c19e3d58)
==========

to

==========
Handle Security Key requests from outside the remoted session correctly

The recent Mojo conversion changed the communication pattern between the
IPC Server and Client classes used for remote security key message
forwarding.  This change has caused a regression in the scenario where
the security key request originates from outside the remoted session.
The desired behavior is to pass a message to the local SK handler so
it can route/handle the request.  Due to the change in the following
CL, we would instead report that the remote client would handle it,
then return a failure when they sent the request:
https://codereview.chromium.org/2478443002/

The reason for this change is that the session detection logic was wrapped
in the OnChannelConnected() method.  Because you cannot close an IPC channel
from within that method, we would defer the close operation.  With the old
architecture, the client would be waiting for a specific IPC message to
complete the connection (and signal success) but instead would receive
the deferred close/error message and pass on the right message to the local
handler.  This behavior was changed such that the client would now signal
success in its own 'OnChannelConnected()' and then receive the deferred
error.

In order to make this scenario more robust, I have added specific success
and failure IPC messages to be passed to the client from the server and
will use that when establishing the connection.  I've also separated out
the concept of an invalid session vs. and actual connection error so the
IPC client class can provide more accurate details to the local handler.

BUG=674236

Review-Url: https://codereview.chromium.org/2575963002
Cr-Commit-Position: refs/heads/master@{#439685}
(cherry picked from commit afdd0e9701d38723cb5ebae11e4e26a7c19e3d58)

Committed:
https://chromium.googlesource.com/chromium/src/+/b9c016474def2fac457b08c42b63...
==========

[joedow, 2016-12-21 16:24:00]

Committed patchset #1 (id:1) manually as
b9c016474def2fac457b08c42b63a4d09cf5c9f8.