Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Apple Message framework v1278)
Subject: Re: userCtx extra information
From: Robert Newson <rnewson@apache.org>
In-Reply-To: <503F4934.3010007@gmail.com>
Date: Thu, 30 Aug 2012 12:28:28 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <EBE58485-DF28-45AB-9168-856EB4ABD213@apache.org>
References: <503CA33A.6080305@gmail.com>
 <CAJNb-9qEAr7tk4K5EPEcuM5RVxpS0iYSbo3QV49epoYXHs6WtA@mail.gmail.com>
 <CAHZBNKb4K0oatL-i-0SVN2W=xoGF1LijqCcR4Si6_-CdVSxBbg@mail.gmail.com>
 <CAJNb-9rXVM7vkZgK0=hErJ-BSuHzGp5r9mzkMJd8ryebLJqo8Q@mail.gmail.com>
 <CAKNVnzycMA7N7w9jNgiAC6O-rj34F66J=28m1gt-0a8_AcTuew@mail.gmail.com>
 <CAJNb-9oT5s7T3cfnggN5nU6neT8rKyLe33Ay_bR==+8kCPDkig@mail.gmail.com>
 <503F06B4.8010303@gmail.com>
 <CAJNb-9rU+dfe6Ehohxtu0rfjRFRr7S3MQre731SFKo163JqGzQ@mail.gmail.com>
 <503F4934.3010007@gmail.com>
To: user@couchdb.apache.org


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.

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?
>=20
> 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.
>=20
> 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.
>=20
> PS. Sorry for long posts. I have a lot of thoughts to write down)
>=20
> Alex
>=20
> On 30/08/12 12:56, Benoit Chesneau wrote:
>> On Thu, Aug 30, 2012 at 8:22 AM, Aliaksandr Barysiuk
>> <a.barysiuk@gmail.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 =
(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 =
web 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?
>>=20
>> - 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)
>>=20
>> 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 do =
what
>>> Couchdb doesnt' provide out-of-the-box. And even you fix roles to =
have only
>>> strings it is not a big deal to concatenate all my data and put it =
as 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.
>>=20
>>> 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
>>>=20
>> Why sending a user doc isn't enough?
>>=20
>>=20
>>> I'm sure these things make Couchdb better and easy to use for =
commercial
>>> development.
>>>=20
>>> Alex
>>>=20
>>>=20
>>> On 29/08/12 23:05, Benoit Chesneau wrote:
>>>> On Wed, Aug 29, 2012 at 9:54 PM, Gabriel Mancini
>>>> <gabriel.mancini@gmail.com> 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
>>>>> <bchesneau@gmail.com>wrote:
>>>>>=20
>>>>>> On Wed, Aug 29, 2012 at 9:24 PM, Dave Cottlehuber =
<dave@muse.net.nz>
>>>>>> wrote:
>>>>>>> On 29 August 2012 08:21, Benoit Chesneau <bchesneau@gmail.com> =
wrote:
>>>>>>>> On Tuesday, August 28, 2012, Aliaksandr Barysiuk wrote:
>>>>>>>>=20
>>>>>>>>> Hello,
>>>>>>>>>=20
>>>>>>>>> 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
>>>>>>>>>=20
>>>>>>>>> Alex
>>>>>>>>>=20
>>>>>>>> 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.
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> beno=EEt
>>>>>>> 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 is =
expected
>>>>>> in the roles member. We should enforce that.
>>>>>>=20
>>>>>> 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 anything =
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.
>>>>>>=20
>>>>>> - benoit
>>>>>>=20
>>>>>=20
>>>>> --
>>>>> Gabriel Mancini de Campos
>>>>> Arquiteto de Solu=E7=F5es
>>>>>=20
>>>>> +55 (11) 9449-1706
>>>>> gabriel.mancini@gmail.com
>>>>> S=E3o Paulo - SP - Brasil
>>>=20
>=20