incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "john.tiger" <john.tigernas...@gmail.com>
Subject Re: userCtx extra information
Date Thu, 30 Aug 2012 12:14:37 GMT


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
>>> <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?
>>>
>>> - 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 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.
>>>
>>>> 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
>>>>> <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:
>>>>>>
>>>>>>> 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:
>>>>>>>>>
>>>>>>>>>> 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 is
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 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.
>>>>>>>
>>>>>>> - benoit
>>>>>>>
>>>>>> --
>>>>>> Gabriel Mancini de Campos
>>>>>> Arquiteto de Soluções
>>>>>>
>>>>>> +55 (11) 9449-1706
>>>>>> gabriel.mancini@gmail.com
>>>>>> São Paulo - SP - Brasil
>


Mime
View raw message