couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Klo <>
Subject Re: userCtx extra information
Date Thu, 30 Aug 2012 17:06:29 GMT
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

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 access.

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).


Jim Klo
Senior Software Engineer
Center for Software Engineering
SRI International
t.	@nsomnac

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 and
> use this info to auth/reject the user.
> this way we can trigger an 403 http error. this is more "REST" approach i
> guess
> On Thu, Aug 30, 2012 at 9:14 AM, john.tiger <>wrote:
>> On 08/30/2012 05:28 AM, Robert Newson wrote:
>>> In CouchDB 1.2.0 mandatory filters have been added when accessing _users
>>> such that no user can see another users document. So, you can allow signup
>>> (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 authorization
>>> decisions and the CouchDB security model is that these decisions are made
>>> on the user's name and/or the user's roles. Any additional information in
>>> there could also be used for authorization purposes which would alter the
>>> security model. Now, that might not be a bad thing, but it's not something
>>> 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. If
>>> 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
>>> another machine.
>>> The _users db exists to provide authentication/authorization services to
>>> CouchDB, it's unfortunate that it's also a CouchDB database as well as this
>>> leads to misconceptions. Most RDBMS's use system databases to provide a
>>> similar service and, likewise, don't expand those things for application
>>> use.
>> 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.  Then
>> the reverse, a post that creates a user and the user doc from the one form.
>> 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 the
>> couch guide or simply a couch how-to or cookbook wiki, something Couch
>> needs.
>>> B.
>>> On 30 Aug 2012, at 12:06, Aliaksandr Barysiuk wrote:
>>> We have a simple form for user registration with standard fields: fname,
>>>> lname, email, avatar url, etc. We want to have some section on the page
>>>> 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 user
>>>> always have access to it (we don't need to make any additional call). It's
>>>> simple. What is the reason to keep user information separately?
>>>> I have already discuss this question with R.Newson and i can't say that
>>>> i'm satisfied with the answers. Of course to create new user (signup) you
>>>> need to be an admin, but we cannot specify admin credential on the client
>>>> because everyone can use them, right? Other option is to open _usersdb for
>>>> reading and writing which is crazy and totally unacceptable. As a result
>>>> now we use node.js with JSONP call that sent all user info to node server
>>>> and there user entry is saved into _usersdb with admin credentials. Or we
>>>> need to write own authorization logic and use Couchdb as usual storage
>>>> which may takes a lot of time. Signup, reset password functions - usual
>>>> 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 to
>>>> use external system (node.js in our case). It would be great if Couchdb can
>>>> handle it without any other service.
>>>> PS. Sorry for long posts. I have a lot of thoughts to write down)
>>>> Alex
>>>> On 30/08/12 12:56, Benoit Chesneau wrote:
>>>>> On Thu, Aug 30, 2012 at 8:22 AM, Aliaksandr Barysiuk
>>>>> <>  wrote:
>>>>>> I don't understand your position. Now Couchdb user management is
>>>>>> rudimentary state. It even doesn't allow to create new user easily
>>>>>> (without
>>>>>> opening access to _users db or using external service). I understand
>>>>>> that
>>>>>> Couchdb developers bothers more about performance, scalability etc.
>>>>>> But you
>>>>>> totally forgot about simple cases. I'm sure that a big percent of
>>>>>> apps
>>>>>> use user management. So what is the problem to develop convenient
>>>>>> authentication/authorization system? It is normal to have extra
>>>>>> information
>>>>>> in users db.
>>>>> Well you can't put extra informations in the postgresql user database.
>>>>> The question is more why do you want such extra information in this
>>>>> db?
>>>>> - Is this because you don't have access to couchdb internally in your
>>>>> couchapps?
>>>>> - 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
>>>>>> exists. And
>>>>>> it is not a solution 'fix this bug' since it provides easiest way
>>>>>> what
>>>>>> Couchdb doesnt' provide out-of-the-box. And even you fix roles to
>>>>>> only
>>>>>> strings it is not a big deal to concatenate all my data and put it
>>>>>> string
>>>>>> 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 think
>>>>> that roles should be anything but roles. ie things to manage
>>>>> permissions.
>>>>> Conclusion: I don't want to reinvent the wheel and develop own
>>>>>> authentication/authorization mechanism. The existing works well except
>>>>>> 2
>>>>>> things:
>>>>>> - 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
>>>>>> commercial
>>>>>> development.
>>>>>> Alex
>>>>>> On 29/08/12 23:05, Benoit Chesneau wrote:
>>>>>>> On Wed, Aug 29, 2012 at 9:54 PM, Gabriel Mancini
>>>>>>> <>  wrote:
>>>>>>>> but can be nice have sume enable/disable behaviour for user.
We could
>>>>>>>> have anything once partial updates and fetch  will be here.
But it's
>>>>>>>> not the
>>>>>>>> case right now :)
>>>>>>> - benoit
>>>>>>>> On Wed, Aug 29, 2012 at 4:39 PM, Benoit Chesneau
>>>>>>>> <>wrote:
>>>>>>>> On Wed, Aug 29, 2012 at 9:24 PM, Dave Cottlehuber<>
>>>>>>>>> wrote:
>>>>>>>>>> On 29 August 2012 08:21, Benoit Chesneau<>
>>>>>>>>>> wrote:
>>>>>>>>>>> On Tuesday, August 28, 2012, Aliaksandr Barysiuk
>>>>>>>>>>> Hello,
>>>>>>>>>>>> We store some extra information in _users
db and now we are
>>>>>>>>>>>> looking a
>>>>>>>>>>> way
>>>>>>>>>> to populate session.userCtx with these extra values.
Is it possible
>>>>>>>>>>>> at
>>>>>>>>>>> all?
>>>>>>>>>> Thank you
>>>>>>>>>>>> Alex
>>>>>>>>>>>> user db isn't done for that. this db exists
to authenticate
>>>>>>>>>>> users and
>>>>>>>>>> only
>>>>>>>>>> that. You should better save the profiles in another
db. Also
>>>>>>>>>>> there is
>>>>>>>>>> no
>>>>>>>>>> such things like session in couchdb by itself.
>>>>>>>>>>> benoît
>>>>>>>>>> Any good reasons why we couldn't / shouldn't support
something that
>>>>>>>>>> eases this pain? Putting in a second db simply to
store some basic
>>>>>>>>>> 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 shouldn't
>>>>>>>>> allow that and it should be fixed. Only a list of strings
>>>>>>>>> expected
>>>>>>>>> in the roles member. We should enforce that.
>>>>>>>>> For security reasons I don't think it's good to have
more data in
>>>>>>>>> the
>>>>>>>>> doc other than the login, roles, password and possibly
>>>>>>>>> about
>>>>>>>>> permissions ( some would argue that the users db shouldn't
exist at
>>>>>>>>> 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 use
>>>>>>>>> of
>>>>>>>>> this profile by others. Only the user or an admin can
have access to
>>>>>>>>> the doc. Which is good imo.
>>>>>>>>> - benoit
>>>>>>>>> --
>>>>>>>> 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

View raw message