couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gabriel Mancini <gabriel.manc...@gmail.com>
Subject Re: userCtx extra information
Date Thu, 30 Aug 2012 15:13:49 GMT
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 <john.tigernassau@gmail.com>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
>>>> <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
>>>>>>>
>>>>>>
>>
>


-- 
Gabriel Mancini de Campos
Arquiteto de Soluções

+55 (11) 9449-1706
gabriel.mancini@gmail.com
São Paulo - SP - Brasil

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message