on peer transfers of client connections), so have PresentsSession handle that in both starting
and resuming a session (and takes out a synchronized call in ClientManager).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6495 542714f4-19e9-0310-aa3c-eee0fc999fb1
server). It can then be used to encrypt further data during the session.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6492 542714f4-19e9-0310-aa3c-eee0fc999fb1
(In Who, we need to stream com.threerings.geom.Vector2, so we need a custom Streamer for it)
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6487 542714f4-19e9-0310-aa3c-eee0fc999fb1
{Client.setRequireSecureAuth} then if the client fails to create a secure channel with the server,
an auth request with no credentials will be sent. The supplied Authenticator will need to handle
this situation to send the appropriate response back to the client (ie: tell it to download the
latest version).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6480 542714f4-19e9-0310-aa3c-eee0fc999fb1
eventually change how the handshake works, we can maintain backwards compatability with the old
clients
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6479 542714f4-19e9-0310-aa3c-eee0fc999fb1
when sent to the server.
To implement a secure authentication channel:
- Create a key pair using the com.threerings.presents.tool.KeyPairGen tool. You will need to
distribute the public key with your client, and the private key with the server.
- On your server during initialization, use PresentsConnectionManager.setPrivateKey to set the
private key. It can take the key string gerenated by KeyPairGen. This will return true if the
key was sucessfully set and the server supports the encryption necessary.
- On your client before authenticating, use Client.setPublicKey to set the public key. As with
setPrivateKey, it will return true if the client supports the encryption necessary.
That's it! You should now be authenticating over a secure encrypted channel. The server can
still accept unsecured authentication attempts (for the purpose of telling the client it needs a
new version to get the server's public key). A failure to decrypt the client credientials on the
server will return a new "m.failed_to_secure" authentication code.
Handshake process:
- The client generates a random 128-bit key, and encodes it with the public key using a 32-bit
salt (PublicKeyCredentials). This is sent to the server as a SecureRequest.
- The server decrypts the i128-bit key using its private key and verifies it against the salt. If
verification fails, a failed secure response is returned and the client will authenticate over a
clear channel. If verification succeeds, the server generates a random 128-bit AES key and
encodes it with the 128-bit key sent from the client. This is sent back to the client as a
SecureResponse.
- The client will decode the AES key sent from the server (using the random key it generated at
the start of the handshake). Using the AES key, the client will encrypt their credentials using
an AESAuthRequest and send it to the server.
- The server can now decrypt the credentials from the client and pass the AESAuthRequest to the
configured authenticators to complete authentication. If the server fails to decrypt the
credentials a "m.failed_to_secure" authentication code is returned to the client.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6477 542714f4-19e9-0310-aa3c-eee0fc999fb1
A concrete example of this is on PlaceObjects - If the server tells users to leave a place and then calls shutdown on the PlaceManager, thus destroying the object, the client will receive the leave-place message, queue up an unsubscribe, receive the destroy message, remove the object from their object cache, and then be unable to unsubscribe back to the server due to no longer having the DObject in question.
Now, if a PresentsSession received a destroy event for an object its client is subscribed to, it will delete the subscription, and instead note the oid as a destroyed subscription for use in validation if lingering unsubscribe requests are pending (they can frequently be). This still potentially leaks the oid int until the session is ended, but the DObject can be collected.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6475 542714f4-19e9-0310-aa3c-eee0fc999fb1
Leaving RootDObjectManager's declaration of newInterval() alone, because it contains docs that are specific to its implementation.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6474 542714f4-19e9-0310-aa3c-eee0fc999fb1
(as we sometimes do when we transfer a player between peers in Project X).
Technically we probably shouldn't be streaming the marshallers in that case,
but doing this (and clearing the marshaller on the receiving end) is simpler
than clearing, streaming, and restoring; or settings things up so that the
marshaller is specifically excluded from streaming in transfers.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6467 542714f4-19e9-0310-aa3c-eee0fc999fb1
the default comparison methods in a symmetric way (so that it doesn't matter
which of the two objects' equals/compareTo methods was called).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6465 542714f4-19e9-0310-aa3c-eee0fc999fb1
match DSets and setting attributes. With the old behvaior, if a client subscribed to a DObject and
modified an OidList on it in a single pass, it could miss the modification. The DObject is
serialized immediately when the server gets the subscription request, but events aren't sent for
that subscription till it's processed the next time the omgr queue comes round.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6420 542714f4-19e9-0310-aa3c-eee0fc999fb1
Mike Thomas