Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of cgsmcmlxxv@gmail.com designates
 209.85.215.180 as permitted sender)
Message-ID: <4F0E1223.8050508@gmail.com>
Date: Wed, 11 Jan 2012 23:50:11 +0100
From: CGS <cgsmcmlxxv@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15
MIME-Version: 1.0
To: user@couchdb.apache.org
Subject: Re: how to implement a database for every user
References: 
 <CA+w3y1gL2iCDt3fRLE+VumyL7ynXapEw5Sc3KF+J2hFW51S=AQ@mail.gmail.com>
In-Reply-To: 
 <CA+w3y1gL2iCDt3fRLE+VumyL7ynXapEw5Sc3KF+J2hFW51S=AQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


Hi Alex,

One option is AJAX (for example, see jQuery AJAX where you should define 
something like $.ajax{type: "PUT", url: 
"http://barbalex.iriscouch.com/"+options.userdb, ...}, with 
options.userdb should be passed from the main registration page). This 
option has security problems (I've seen you are not so interested in 
security now, but I am sure you will be later) like:
1. the JS script can be seen by everyone (even if packed, it can be hacked);
2. using multiple redirection can hide a bit the things, but it still 
can be hacked (gmail uses this method as a security part to protect its 
code from hackers).

The advantage of this method is that you can delay the redirection until 
your replication is finished (just loop over a test function which 
checks for the existence of the required documents and when all the 
tests are passed, redirect the user toward his/her new database).

Another option is external trigger. That means, your user triggers the 
creation of a document in a db of your choice and instruct CouchDB to 
trigger a certain external application every time a new document 
appears. The external application can try to access the document (in 
which you have the name of the database for that user) and to issue a 
HTTP PUT request toward CouchDB. I am not familiar with iriscouch 
(Jason, please, accept my apologies for that), so, I don't know how the 
external triggers are handled in iriscouch (and therefore I cannot give 
you, Alex, more details about the implementation of this option).

The last option I can think of now, is the one I use, but I think it is 
useful only in the case you have your own server. Nevertheless, I give 
it to you for the completeness reason only. This option is a secured 
version of the first option, in which the database creation is managed 
at the HTTP server level. This is, set CouchDB server access via another 
HTTP server, so, the admin password and all the sensitive data are out 
of reach (e.g., I use YAWS in which I define Erlang modules to handle 
the connection with the database, so, even if my .yaws page crashes, the 
code cannot be seen in the browser - pretty annoying method at the 
debugging level though :) ).

I suppose you can try the first option with multiple redirection (at 
each level the page should have a specific task). Later on, you can 
improve the security of this method.

Good luck!
CGS


On 01/11/2012 05:18 PM, Alexander Gabriel wrote:
> Hi
>
> I have a couchapp hosted on iriscouch (
> http://barbalex.iriscouch.com/evab/_design/evab/index.html).
> My users should only be able to read their own documents.
> Additionally there are public documents that need to be pulled from a
> central database (roughly 23 megabytes!).
> Additionally some of the user documents should be written to the central
> database.
>
> I understand the way to do this is:
>
>     1. User signs up
>     2. this generates a doc
>     3. external software listens to the _changes feed sees the doc. It
>     creates the database, assigns the user as admin, configures continuous
>     filtered replication from and to the central database
>     4. the user is handed over to this database (couchapp)
>     5. I guess I will have to tell the user to wait until all public
>     documents have replicated
>
>
> These are my questions:
>
>     - How can I implement the external software?
>     - How can I make sure that it is always running?
>     - How can the brand new user database tell when all the public documents
>     have been replicated so it can inform the user? It can't do anything anyway
>     before the design doc hasn't been replicated. So that would have to be
>     replicated first
>     - Are there articles/tutorials/examples showing this?
>
> I'm a novice and so far I only have some experience with javascript and
> couchdb. Would be great if this could be done using that knowledge. Can the
> external software also be a couchapp, maybe integrated into the central
> database?
>
> Well, that is plenty asked. If I manage to pull this through I would gladly
> add an article to the wiki.
>
> Alex
>