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
