Am 25.03.2011 16:37, schrieb Nebu Pookins:
The two partial solutions that immediately come to mind are:
1) When a user downloads their own instance of the CouchApp, it's
"tied" to that user. Bob cannot use Alice's copy of the CouchApp to
blog; but if Alice had the foresight to download a copy both under her
account and under Bob's account, then they can still share a laptop
for offline access, although in different copies of the app.
2) Use public key cryptography and signatures, such that every change
is signed, and every server can verify the signature of every
modification to see if it really came from who it should be coming
from.
Solution (1) is unpleasant for the end user experience, but otherwise
seems straightforward to implement.
Solution (2) seems much more difficult to implement (JavaScript's
treating of all numerics as floating points, whereas Cryptography
typically works entirely with very big (e.g. 128bit, 256 bit, 4096
bit, etc.) integers makes the two look like a mismatch without first
writing a Bigint library), and while in theory seems to be much more
pleasant for end users, in practice I believe the user would not only
need to provide a password, but also their private key renders the
user experience unpleasant again.
I'll probably end up going with solution (2) because the proposed app
we're building will have to deal with banking and financial data, so
we're going to have to have some cryptography in there anyway, but I'm
just making sure I'm not missing anything (such as CouchDB already
having some sort of encryption library built in).
Thanks again, Patrick, for clearing things up for me.
Not sure if it will fit your needs, but there also is solution 3:
Have 4 (filtered) replications.
One pair using Alices credentials pulling/pushing Alices blogposts and
another two using Bobs credentials to push/pull his blogposts.
For the "main" server there is no difference if the user is logged in
using the webinterface, curl, whatever or if it's his replication.
--
Stefan
