Like I said there are some features actually missing in couch that
would ease that. (partial updates and partial fetch). Of course a view
could be use to see only profile but that would be a hack.
I won't argue there - I've not thought enough about how one designs a secure document db in CouchDB vs how one designs secure RDBMS. Both are fundamentally different, and require you to cast preconceived notions aside on how security is should be applied by using reference from one model and trying to force it onto the other.
And this is not only about being a db or something alternative. This
is more about security here. Even in the old world data for
authentication and profiles are generally separated. For a good
reason. This isn't generally the same person that have access to them.
And personnaly I would see a profile linked to a user but not in the
I think that's a false premise to base separation upon. Security should *always* apply to the effective user consistently to determine access control. In a large system, if I don't do that, one could unintentionally elevate user permissions. This 'idea' that users being separated from 'logins' come from traditional RDBMS design through normalization for enhancing the performance of lookups and relationships, not because it couldn't be combined. Systems like MS SQL, MySQL and others allow you to map an external user (which is typ tied to system access rights) and to an internal user (which is tied to schema access rights). All of this which was coined and conceived before document db's ever really existed. And even in those models - they are following an extremely orthogonal design. Even in more modern solutions, that use SSO/LDAP for authentication - there's one user object that's used everywhere from user application login down to validating access for an app that connects to the SQL DB (think Active Directory + MS SQL + SharePoint, many users have access to the same data - defined by roles stored in AD; access authenticated by Roles/Groups assigned in MSSQL).
CouchDB works with documents, users should be documents and not require a "JOIN" of any sort to fetch a different document relating to that user. That "JOIN" operation isn't native to CouchDB and would break orthogonality.
Nothing that I'm describing prevents you from adopting an old world view mentality, I'm just encouraging that we follow the CouchDB design pattern and like RDBMS - be consistent and orthogonal in the way objects are stored and organized, including internal system objects, and store users as a single document. In CouchDB, would you store an ISBN for a book document in separate document from it's title, language, and abstract? Why would you do that with a user then?
Also I'm pretty sure that the reason people are asking about
populating this userCtx is because they lack the possibility to query
internally the db. This can be changed.
Agreed. However the general argument for non-separation of user login from profile is more at question. userCtx is more than likely just a result of what is minimally expected to be present in the data model. It's analogous to requesting a view with just ids or with docs. Extending to add internal query, which would enable lookup, seems like a more involved solution, and creates potential for real performance issues (think cascading triggers) and security breach.
Adding query is to get additional data from a specific object already being partially injected, feels like you're bringing a machine gun to knife fight.
On 08/30/2012 10:06 AM, Jim Klo wrote:
Been following this thread a bit, and thought there's a unique
characteristic of CouchDB here that's being overlooked that should allow us
to address this problem in potentially a unique way.
There's basically 2 camps (dare I say religions) here:
1) Traditional DB folks CouchDB's _users is special an should be reserved
for "applications as clients" and that end users should be stored
differently and separately. Most clients that connect to the db will some
application that will manage data access. App logic will decide who gets to
read/write - not the user who is actually connecting to the DB; their the
2) App developers: Who just want an HTTP API to save user info, utilize
for authentication, session management, and access control - they don't want
to rebuild this for every app, and certainly aren't interested in having to
write an additional server-side tier to make this work securely. Real people
use apps, real people are the ones who actually have where with all to fill
out a form and place it into some storage area, read some bit of privileged
or non-privileged info, etc... they don't really give a rip about some
middle-man user who's logic decides if they have the right credentials to
CouchDB is a unique product: It can act as both a HTTP application server
and an indexed document store. I can't think of another solution that does
this so elegantly. Because of this, I think _users should be treated
differently than a traditional DB that uses JDBC/Named Pipe/ODBC/pick your
db connectivity poison to access the DB. Ultimately, in both camps, users
are being used to restrict the level of access to documents. CouchDB for
the most part allows simple apps to 'eliminate the middle tier', which is
what the traditional db camp is trying, i think, to argue is less secure,
and thus one needs to mimic the middle tier and use isolation of data to
protect that _users db. The reality the way the CouchDB user model, IMHO can
actually be more secure, because the same user who is connecting to the app
via web, can be the exact same user that reads/writes to the document
store... no more middle tier application with god like powers having to
mediate user permissions.
CouchDB, for the most part is very orthogonally designed. Configuration /
Users / Replication / Document DB are all essentially stored/treated in the
same manner (or at least shares a common API) that is more or less
schema-less (config is a tad different in that it persists to an INI file).
The _users db should continue to follow the same schema-less design it has
been; documents to be used for authentication should need to follow nothing
more than a duck typed convention any extra data should just be treated as
noise to parts of the core app that don't need it. If you want to store
additional info in user document, go for it - authentication should just
ignore it - its not hurting anyone, really.
Those arguing about making the _users db holy by hiding it completely and
limiting what you can store in the object breaks the fantastic orthogonality
that CouchDB enjoys today.
My vote? Continue keeping CouchDB orthogonal, in fact make it even more
so! IMHO - I think being able to store additional data that can be retrieved
via userCtx would be good; however I think there should be a flag that is
used when querying to include the extra data,(like include_docs=true, but
maybe full_userCtx=true)?. As an app developer - you shouldn't need access
to all of the users additional attributes for every request. That is
potentially a lot of extra data (equates to memory use/etc) that would go
unused on probably 90% of the requests made. The middle tier / traditional
db guys & gals are happy - they can still do their own thing through god and
demi-god apps and manage access via their middle-tier (god help them!); and
the CouchApp guys & gals can go on with their own thing and leverage built
in _users functionality within CouchDB and get them access to the additional
userCtx as needed in their list/show/etc functions (heck they are already
double-dipping on the appserver / db combo).
Senior Software Engineer
Center for Software Engineering
On Aug 30, 2012, at 8:13 AM, Gabriel Mancini wrote:
I think this can be flexible to offer some aditional information as
optional feature in userCtx.
and with possibility to create a design document with validation login
use this info to auth/reject the user.
this way we can trigger an 403 http error. this is more "REST" approach i
On Thu, Aug 30, 2012 at 9:14 AM, john.tiger <email@example.com
On 08/30/2012 05:28 AM, Robert Newson wrote:
In CouchDB 1.2.0 mandatory filters have been added when accessing
such that no user can see another users document. So, you can allow
(jquery.couch.js includes such a function) safely.
As for expanding the userCtx, it's not something we're rejecting out of
hand or to annoy you. The userCtx object is provided to allow
decisions and the CouchDB security model is that these decisions are
on the user's name and/or the user's roles. Any additional information
there could also be used for authorization purposes which would alter
security model. Now, that might not be a bad thing, but it's not
to be done lightly.
Further, practical points to consider. The name and roles are needed
often and so they are stored in an in-memory cache. The larger you make
userCtx, the less caching will be possible and performance will suffer.
you then further consider a sharded CouchDB system (after the BigCouch
merge) then the user information you need, on a cache miss, might be on
The _users db exists to provide authentication/authorization services
CouchDB, it's unfortunate that it's also a CouchDB database as well as
leads to misconceptions. Most RDBMS's use system databases to provide a
similar service and, likewise, don't expand those things for
from a good practice standpoint, Robert and Benoit are correct. from a
coding standpoint, maybe someone has a ready made example of a view that
shows a check for auth/auth then a query on the associated user doc.
the reverse, a post that creates a user and the user doc from the one
It's fairly simple stuff but would save time and effort for everyone who
is using something like this (many apps). This "how-to" could go into
couch guide or simply a couch how-to or cookbook wiki, something Couch
On 30 Aug 2012, at 12:06, Aliaksandr Barysiuk wrote:
We have a simple form for user registration with standard fields:
lname, email, avatar url, etc. We want to have some section on the
that shows some of these field after user successfully logged in (like
'Logged in as $fname + #lname', show avatar). Nothing special. For me
userCtx is perfect place to store such information, because logged
always have access to it (we don't need to make any additional call).
simple. What is the reason to keep user information separately?
I have already discuss this question with R.Newson and i can't say
i'm satisfied with the answers. Of course to create new user (signup)
need to be an admin, but we cannot specify admin credential on the
because everyone can use them, right? Other option is to open _usersdb
reading and writing which is crazy and totally unacceptable. As a
now we use node.js with JSONP call that sent all user info to node
and there user entry is saved into _usersdb with admin credentials. Or
need to write own authorization logic and use Couchdb as usual storage
which may takes a lot of time. Signup, reset password functions -
operations on every web site.
Conclusion: couchdb makes development of web apps very convinient. But
user management is the important part of each web app and now we HAVE
use external system (node.js in our case). It would be great if
handle it without any other service.
PS. Sorry for long posts. I have a lot of thoughts to write down)
On 30/08/12 12:56, Benoit Chesneau wrote:
On Thu, Aug 30, 2012 at 8:22 AM, Aliaksandr Barysiuk
<firstname.lastname@example.org <mailto:email@example.com>> wrote:
I don't understand your position. Now Couchdb user management is in
rudimentary state. It even doesn't allow to create new user easily
opening access to _users db or using external service). I understand
Couchdb developers bothers more about performance, scalability etc.
totally forgot about simple cases. I'm sure that a big percent of
use user management. So what is the problem to develop convenient
authentication/authorization system? It is normal to have extra
in users db.
Well you can't put extra informations in the postgresql user
The question is more why do you want such extra information in this
- Is this because you don't have access to couchdb internally in your
- Because you need to be an admin to create a user? (ie lacking of a
permission to create a user for anyone)
- other? (and why in this case)
And it's also normal that people want to see this information
in session. Using roles for that just shows you that the problem
it is not a solution 'fix this bug' since it provides easiest way do
Couchdb doesnt' provide out-of-the-box. And even you fix roles to
strings it is not a big deal to concatenate all my data and put it
in a role. It just adds some extra work on parsing that.
Everything is possible. But doing it the clean way is hard. I do
that roles should be anything but roles. ie things to manage
Conclusion: I don't want to reinvent the wheel and develop own
authentication/authorization mechanism. The existing works well
- add extra info to _users and being able to see it in the userCtx
- add signup function to Session API
Why sending a user doc isn't enough?
I'm sure these things make Couchdb better and easy to use for
On 29/08/12 23:05, Benoit Chesneau wrote:
On Wed, Aug 29, 2012 at 9:54 PM, Gabriel Mancini
but can be nice have sume enable/disable behaviour for user. We
have anything once partial updates and fetch will be here. But
case right now :)
On Wed, Aug 29, 2012 at 4:39 PM, Benoit Chesneau
On Wed, Aug 29, 2012 at 9:24 PM, Dave Cottlehuber<firstname.lastname@example.org
On 29 August 2012 08:21, Benoit Chesneau<email@example.com
On Tuesday, August 28, 2012, Aliaksandr Barysiuk wrote:
We store some extra information in _users db and now we are
to populate session.userCtx with these extra values. Is it
user db isn't done for that. this db exists to authenticate
that. You should better save the profiles in another db. Also
such things like session in couchdb by itself.
Any good reasons why we couldn't / shouldn't support something
eases this pain? Putting in a second db simply to store some
profile info seems daft. And as others have found, you can store
anything you like in roles.
Well I think that storing anything in a role is a bug. We
allow that and it should be fixed. Only a list of strings is
in the roles member. We should enforce that.
For security reasons I don't think it's good to have more data in
doc other than the login, roles, password and possibly anything
permissions ( some would argue that the users db shouldn't exist
all). You don't protect the same the access to a user doc or a a
profile doc. And the way it is designed right now prevent any
this profile by others. Only the user or an admin can have access
the doc. Which is good imo.
Gabriel Mancini de Campos
Arquiteto de Soluções
+55 (11) 9449-1706
São Paulo - SP - Brasil
Gabriel Mancini de Campos
Arquiteto de Soluções
+55 (11) 9449-1706
São Paulo - SP - Brasil