couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <bchesn...@gmail.com>
Subject Re: userCtx extra information
Date Thu, 30 Aug 2012 09:56:43 GMT
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