Background
Right now, I'm trying to build an app with couchDB/couchapp that would store persistent and crucial information from the user, and am stuck on the steps required for user signup with couchapp.
Essentially, what I want to do is to have a simple signup form that users can use to register an account for using my app. This would entail creation of a new user in the couchdb _users database, and the creation of a new database, with the new user assigned the role of database admin.
All that requires server admin credentials.
Ideally, I'd love to be able to mak开发者_运维技巧e a call using one of the jquery.couch.js
functions, but there doesn't seem to be a secure way to do that. (or is there??)
Question
What is the most efficient yet secure way to offload this task to a middle-layer software or otherwise?
By efficient, I mean needing the least amount of steps for the user, not necessarily the least amount of hassle for me.
As of right now, I've set up a separate node.js server that receives signup requests. My couchDB server admin credentials are stored as supposed private variables on the node server.js
file. I then POST any db creation request back to couchDB using couch-client
.
Am I jumping through too many (potential insecure) hoops here? Is there a better way to ensure a secure signup process?
Thanks.
An admin user is required to create a database and assign database admins.
Dominic's answer is great. However an alternative is to keep the direct couchapp architecture and run your admin code external, outside the user-couch chain.
For example, in NodeJS, connect to CouchDB as an admin. Query /_users/_changes?feed=continuous&include_docs=true
. You will receive a data event in real-time when users are created. When you see a new user, create the database and assign them as the admin.
The client code can poll for their new database. Or, the client can also query /_users
via the _changes
COMET feed too. Either way, once the browser knows that the account is set up, you can show it to the user in the UI.
Proxies (3-layer architecture) are great. There's nothing they can't do. However, I often prefer the architecture of "CouchDB with an external agent" for two reasons:
- It is simple. There is one web server. Users connect to CouchDB. You connect to CouchDB. Everything is in the database. There are fewer configuration and maintenance issues.
- It is flexible. You can write the external client in any language, running from any server. You write one big app to do everything, or many small apps to focus on one task each (e.g. creating new databases, emailing users for lost passwords, notifying you if a database is too large, etc. etc.).
I've used node.js in the way you are describing. It's no different from using middleware like PHP to communicate with MySQL. As robust as the API is for CouchDB, it's still a good idea to use something else in the middle so you can have content served up without the need for AJAX. (especially if you need anything more complex than a single entity or a list of entities)
If you decide to continue with a direct CouchApp, you'll need to use a proxy server to route HTTPS requests to the CouchDB server itself. (Nginx and Apache are common examples of this use case) If you can't use that, there's an article in the wiki about adding a layer of encryption to the client-side. I found out on the wiki that native SSL support will be added with v1.1 (and is supported in the trunk of the source)
(Btw, all these articles I came across via "How-to Guides" on the CouchDB Wiki)
精彩评论