summaryrefslogtreecommitdiff
path: root/server
diff options
context:
space:
mode:
authordrebs <drebs@leap.se>2017-05-04 15:05:40 +0200
committerdrebs <drebs@leap.se>2017-05-04 15:05:40 +0200
commit6008e999eea82bb4355b086453be42414a4d60c9 (patch)
treeeba379e13b0a79ea026aa06d5bc0c395d61c9516 /server
parent486909fdf644376dda282482565cc8fd70cff3e1 (diff)
[doc] cleanup old documentation
Diffstat (limited to 'server')
-rw-r--r--server/src/leap/soledad/server/__init__.py65
1 files changed, 2 insertions, 63 deletions
diff --git a/server/src/leap/soledad/server/__init__.py b/server/src/leap/soledad/server/__init__.py
index 6640bab4..a4080f13 100644
--- a/server/src/leap/soledad/server/__init__.py
+++ b/server/src/leap/soledad/server/__init__.py
@@ -17,69 +17,8 @@
"""
-A U1DB server that stores data using CouchDB as its persistence layer.
-
-General information
-===================
-
-This is written as a Twisted application and intended to be run using the
-twistd command. To start the soledad server, run:
-
- twistd -n web \
- --wsgi=leap.soledad.server.application.wsgi_application \
- --port=X
-
-An initscript is included and will be installed system wide to make it
-feasible to start and stop the Soledad server service using a standard
-interface.
-
-Server database organization
-============================
-
-Soledad Server works with one database per user and one shared database in
-which user's encrypted secrets might be stored.
-
-User database
--------------
-
-Users' databases in the server are named 'user-<uuid>' and Soledad Client
-may perform synchronization between its local replicas and the user's
-database in the server. Authorization for creating, updating, deleting and
-retrieving information about the user database as well as performing
-synchronization is handled by the `leap.soledad.server.auth` module.
-
-Shared database
----------------
-
-Each user may store password-encrypted recovery data in the shared database.
-
-Recovery documents are stored in the database without any information that
-may identify the user. In order to achieve this, the doc_id of recovery
-documents are obtained as a hash of the user's uid and the user's password.
-User's must have a valid token to interact with recovery documents, but the
-server does not perform further authentication because it has no way to know
-which recovery document belongs to each user.
-
-This has some implications:
-
- * The security of the recovery document doc_id, and thus of access to the
- recovery document (encrypted) content, as well as tampering with the
- stored data, all rely on the difficulty of obtaining the user's password
- (supposing the user's uid is somewhat public) and the security of the hash
- function used to calculate the doc_id.
-
- * The security of the content of a recovery document relies on the
- difficulty of obtaining the user's password.
-
- * If the user looses his/her password, he/she will not be able to obtain the
- recovery document.
-
- * Because of the above, it is recommended that recovery documents expire
- (not implemented yet) to prevent excess storage.
-
-The authorization for creating, updating, deleting and retrieving recovery
-documents on the shared database is handled by `leap.soledad.server.auth`
-module.
+The Soledad Server allows for recovery document storage and database
+synchronization.
"""
import six.moves.urllib.parse as urlparse