WebCollab: Difference between revisions

Line 63:

The large amount of polling required here represents a potential decrease in efficiency. To achieve high efficiency, the client must employ a form of "long polling" or similar push-like technique. It is not clear whether such behavior can work with a typical unmodified WebDAV server.

===The Type-1 SugarHTTPCollab Server->Server Interface===

This interface is the same as the Type-0, updated to include directories and optionally locking.

JSCollab does not require any concurrency control, so locking is only relevant if it is implemented in a fashion that is at least somewhat secure against a malicious client. One obvious way to do this is for anyone who locks a path to issue a message indicating "I know the secret token for this lock". If any other server receives a request to modify or unlock a locked path, it must (privately*) forward the token from the request to the server that knows the token. If the token is correct, that server will issue a broadcast message, "X knows the secret token for the lock"; otherwise it will privately respond "no". The broadcast message forms a chain of trust from the creator of the lock, indicating who knows the token. Servers must reject requests to delete, modify, or unlock a file from a server that has not been identified as knowing the token.

This does not resolve concurrency issues, but it does prevent a malicious user from deleting locked files without knowledge of the secret token.

*: If private transmissions are not available, the system could instead transmit a cryptographic hash of the concatenation of the token and the sender's Telepathy identifier, which can easily be verified by the server, but cannot be reused.

@@ Line 63: / Line 63: @@
 The large amount of polling required here represents a potential decrease in efficiency.  To achieve high efficiency, the client must employ a form of "long polling" or similar push-like technique.  It is not clear whether such behavior can work with a typical unmodified WebDAV server.
+===The Type-1 SugarHTTPCollab Server->Server Interface===
+This interface is the same as the Type-0, updated to include directories and optionally locking.
+JSCollab does not require any concurrency control, so locking is only relevant if it is implemented in a fashion that is at least somewhat secure against a malicious client.  One obvious way to do this is for anyone who locks a path to issue a message indicating "I know the secret token for this lock".  If any other server receives a request to modify or unlock a locked path, it must (privately*) forward the token from the request to the server that knows the token.  If the token is correct, that server will issue a broadcast message, "X knows the secret token for the lock"; otherwise it will privately respond "no".  The broadcast message forms a chain of trust from the creator of the lock, indicating who knows the token.  Servers must reject requests to delete, modify, or unlock a file from a server that has not been identified as knowing the token.
+This does not resolve concurrency issues, but it does prevent a malicious user from deleting locked files without knowledge of the secret token.
+*: If private transmissions are not available, the system could instead transmit a cryptographic hash of the concatenation of the token and the sender's Telepathy identifier, which can easily be verified by the server, but cannot be reused.