userCtx extra information

[Aliaksandr Barysiuk <a....@gmail.com>]

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

Re: userCtx extra information

[Wendall Cada <we...@83864.com>]

On 08/30/2012 12:08 PM, Robert Newson wrote:
> "An example of this is a comments thread moderator. They need permissions to edit portions of a doc that doesn't belong to them. Is it proposed that I just make everyone an admin?"
>
> No. You would invent a role called "moderator". You would assign this to users you wish to be moderators, and your validate_doc_update function would prevent users who don't have the "moderator" role from editing portions of docs that don't belong to them.
My example here is bad, trying to keep it simple. I understand that this 
would be done through validation. The situation is that I have non-admin 
roles where the user can create other users, assign users to specific 
roles. This is necessary for our use-case. Is there a way to do this in 
a non-admin role? Or are there ways to have different levels of 
administrators?

A better example is that you'd have a lead moderator. They have a 
non-admin account. They need to be able to add other users to the 
moderator role. This type of question comes up frequently, and this type 
of behavior combined with attributes which are typically stored in the 
userCtx and reside in the users session allow for fine grained control 
of user behavior without having to use admin accounts for anything but 
creating databases and other admin accounts.

Maybe my understanding of this is completely incorrect here. But I'm not 
seeing any way possible to replace a third party authentication system 
with CouchDB except for the most simplistic situations possible.

Wendall
> B.
>
> On 30 Aug 2012, at 19:38, Wendall Cada wrote:
>
>> An example of this is a comments thread moderator. They need permissions to edit portions of a doc that doesn't belong to them. Is it proposed that I just make everyone an admin?

Re: userCtx extra information

[Robert Newson <rn...@apache.org>]

"An example of this is a comments thread moderator. They need permissions to edit portions of a doc that doesn't belong to them. Is it proposed that I just make everyone an admin?"

No. You would invent a role called "moderator". You would assign this to users you wish to be moderators, and your validate_doc_update function would prevent users who don't have the "moderator" role from editing portions of docs that don't belong to them.

B.

On 30 Aug 2012, at 19:38, Wendall Cada wrote:

> An example of this is a comments thread moderator. They need permissions to edit portions of a doc that doesn't belong to them. Is it proposed that I just make everyone an admin?

Re: userCtx extra information

[Jim Klo <ji...@sri.com>]

> 
> Like I said there are some features actually missing in couch that
> would ease that. (partial updates and partial fetch). Of course a view
> could be use to see only profile but that would be a hack.
> 

I won't argue there - I've not thought enough about how one designs a secure document db in CouchDB vs how one designs secure RDBMS.  Both are fundamentally different, and require you to cast preconceived notions aside on how security is should be applied by using reference from one model and trying to force it onto the other.

> And this is not only about being a db or something alternative. This
> is more about security here. Even in the old world data for
> authentication and profiles are generally separated. For a good
> reason. This isn't generally the same person that have access to them.
> And personnaly I would see a profile linked to a user but not in the
> same doc.
> 

I think that's a false premise to base separation upon. Security should *always* apply to the effective user consistently to determine access control. In a large system, if I don't do that, one could unintentionally elevate user permissions. This 'idea' that users being separated from 'logins' come from traditional RDBMS design through normalization for enhancing the performance of lookups and relationships, not because it couldn't be combined. Systems like MS SQL, MySQL and others allow you to map an external user (which is typ tied to system access rights) and to an internal user (which is tied to schema access rights).  All of this which was coined and conceived before document db's ever really existed.  And even in those models - they are following an extremely orthogonal design.  Even in more modern solutions, that use SSO/LDAP for authentication - there's one user object that's used everywhere from user application login down to validating access for an app that connects to the SQL DB (think Active Directory + MS SQL + SharePoint, many users have access to the same data - defined by roles stored in AD; access authenticated by Roles/Groups assigned in MSSQL). 

CouchDB works with documents, users should be documents and not require a "JOIN" of any sort to fetch a different document relating to that user.  That "JOIN" operation isn't native to CouchDB and would break orthogonality.

Nothing that I'm describing prevents  you from adopting an old world view mentality, I'm just encouraging that we follow the CouchDB design pattern and like RDBMS - be consistent and orthogonal in the way objects are stored and organized, including internal system objects, and store users as a single document. In CouchDB, would you store an ISBN for a book document in separate document from it's title, language, and abstract? Why would you do that with a user then?

> Also I'm pretty sure that the reason people are asking about
> populating this userCtx is because they lack the possibility to query
> internally the db. This can be changed.
> 

Agreed. However the general argument for non-separation of user login from profile is more at question. userCtx is more than likely just a result of what is minimally expected to be present in the data model.  It's analogous to requesting a view with just ids or with docs.  Extending to add internal query, which would enable lookup, seems like a more involved solution, and creates potential for real performance issues (think cascading triggers) and security breach. 

Adding query is to get additional data from a specific object already being partially injected, feels like you're bringing a machine gun to knife fight.

- Jim  

> - benoît
> 
> 
>> Wendall
>> 
>> 
>> On 08/30/2012 10:06 AM, Jim Klo wrote:
>>> 
>>> 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 way.
>>> 
>>> 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
>>> conductor.
>>> 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).
>>> 
>>> Cheers,
>>> 
>>> *
>>> *
>>> *
>>> *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 <john.tigernassau@gmail.com
>>>> <ma...@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 <ma...@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 <ma...@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 <ma...@gmail.com>>wrote:
>>>>>>>>>>> 
>>>>>>>>>>> On Wed, Aug 29, 2012 at 9:24 PM, Dave Cottlehuber<dave@muse.net.nz
>>>>>>>>>>> <ma...@muse.net.nz>>
>>>>>>>>>>>> 
>>>>>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> On 29 August 2012 08:21, Benoit Chesneau<bchesneau@gmail.com
>>>>>>>>>>>>> <ma...@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 <ma...@gmail.com>
>>>>>>>>>>> 
>>>>>>>>>>> São Paulo - SP - Brasil
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> --
>>>> Gabriel Mancini de Campos
>>>> Arquiteto de Soluções
>>>> 
>>>> +55 (11) 9449-1706
>>>> gabriel.mancini@gmail.com <ma...@gmail.com>
>>>> 
>>>> São Paulo - SP - Brasil
>>> 
>>> 
>> 

Re: userCtx extra information

[Dave Cottlehuber <dc...@jsonified.com>]

On 30 August 2012 22:39, Wendall Cada <we...@83864.com> wrote:

>
>  Like I said there are some features actually missing in couch that
>> would ease that. (partial updates and partial fetch). Of course a view
>> could be use to see only profile but that would be a hack.
>>
>> And this is not only about being a db or something alternative. This
>> is more about security here. Even in the old world data for
>> authentication and profiles are generally separated. For a good
>> reason. This isn't generally the same person that have access to them.
>>   And personnaly I would see a profile linked to a user but not in the
>> same doc.
>>
>> Also I'm pretty sure that the reason people are asking about
>> populating this userCtx is because they lack the possibility to query
>> internally the db. This can be changed.
>>
>> - benoīt
>>
>>  I agree with this. The reason for wanting to put data there is the lack
> of support for doing this through a separate document and being able to
> query the db internally for the extended data. Often this data is designed
> not for security but to control application behavior. User settings, etc.
> Currently there isn't a design pattern I can see where this is possible
> without fetching extra docs for every request.
>
> Wendall
>

Very interesting thread.

I think this comes down to 3 key features?

#1 ability to store private / per-user data.
- e.g. for profiles, custom user settings
Today this is only possible in _users db, but that could be extended.

#2 efficient access (single API call preferred) to retrieve extended data,
during authentication/authorisation.
Only possible with the [roles] hack mentioned earlier.
Needs to be something resembling ?include_docs=true to pull in the linked
doc.

#3 access to same info (e.g. in validation docs) than is possible today.

A+
Dave

Re: userCtx extra information

[Wendall Cada <we...@83864.com>]

> Like I said there are some features actually missing in couch that
> would ease that. (partial updates and partial fetch). Of course a view
> could be use to see only profile but that would be a hack.
>
> And this is not only about being a db or something alternative. This
> is more about security here. Even in the old world data for
> authentication and profiles are generally separated. For a good
> reason. This isn't generally the same person that have access to them.
>   And personnaly I would see a profile linked to a user but not in the
> same doc.
>
> Also I'm pretty sure that the reason people are asking about
> populating this userCtx is because they lack the possibility to query
> internally the db. This can be changed.
>
> - benoît
>
I agree with this. The reason for wanting to put data there is the lack 
of support for doing this through a separate document and being able to 
query the db internally for the extended data. Often this data is 
designed not for security but to control application behavior. User 
settings, etc. Currently there isn't a design pattern I can see where 
this is possible without fetching extra docs for every request.

Wendall

Re: userCtx extra information

[Benoit Chesneau <bc...@gmail.com>]

On Thu, Aug 30, 2012 at 8:38 PM, Wendall Cada <we...@83864.com> wrote:
> Jim,
>
> This is a very well thought out response. I believe is correct. In the
> current state, _users is unusable for anything other than 1. I don't even
> bother with that since I have to create an app layer to actually manage
> permissions, so I just don't expose it externally and run admin party and
> use ssh tunneling for sync (mostly because this was setup long before
> 1.2.0).
>
> Really the situation with admin or user as the only roles is bad. I have
> multiple roles. Where admin users are at the top of the food chain, but
> there are users with special permissions who can create regular users, or
> modify specific parts of the documents. An example of this is a comments
> thread moderator. They need permissions to edit portions of a doc that
> doesn't belong to them. Is it proposed that I just make everyone an admin?
> How can this work for couchapps. Maybe I'm missing something, but I don't
> see that this can work at all.
>
> _users just doesn't make sense unless all of the app capabilities get ripped
> out and CouchDB just becomes a database and nothing more. Otherwise, some
> hybrid as Jim mentions needs to happen. There is no reason to think that
> every last bit of the _user doc needs to be cached or in the session. This
> should be able to be retrieved however and stored where it makes sense, with
> the users account data.
>

Like I said there are some features actually missing in couch that
would ease that. (partial updates and partial fetch). Of course a view
could be use to see only profile but that would be a hack.

And this is not only about being a db or something alternative. This
is more about security here. Even in the old world data for
authentication and profiles are generally separated. For a good
reason. This isn't generally the same person that have access to them.
 And personnaly I would see a profile linked to a user but not in the
same doc.

Also I'm pretty sure that the reason people are asking about
populating this userCtx is because they lack the possibility to query
internally the db. This can be changed.

- benoît


> Wendall
>
>
> On 08/30/2012 10:06 AM, Jim Klo wrote:
>>
>> 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 way.
>>
>> 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
>> conductor.
>> 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).
>>
>> Cheers,
>>
>> *
>> *
>> *
>> *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 <john.tigernassau@gmail.com
>>> <ma...@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 <ma...@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 <ma...@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 <ma...@gmail.com>>wrote:
>>>>>>>>>>
>>>>>>>>>> On Wed, Aug 29, 2012 at 9:24 PM, Dave Cottlehuber<dave@muse.net.nz
>>>>>>>>>> <ma...@muse.net.nz>>
>>>>>>>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On 29 August 2012 08:21, Benoit Chesneau<bchesneau@gmail.com
>>>>>>>>>>>> <ma...@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 <ma...@gmail.com>
>>>>>>>>>>
>>>>>>>>>> São Paulo - SP - Brasil
>>>>>>>>>>
>>>>>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Gabriel Mancini de Campos
>>> Arquiteto de Soluções
>>>
>>> +55 (11) 9449-1706
>>> gabriel.mancini@gmail.com <ma...@gmail.com>
>>>
>>> São Paulo - SP - Brasil
>>
>>
>

Re: userCtx extra information

[Wendall Cada <we...@83864.com>]

Jim,

This is a very well thought out response. I believe is correct. In the 
current state, _users is unusable for anything other than 1. I don't 
even bother with that since I have to create an app layer to actually 
manage permissions, so I just don't expose it externally and run admin 
party and use ssh tunneling for sync (mostly because this was setup long 
before 1.2.0).

Really the situation with admin or user as the only roles is bad. I have 
multiple roles. Where admin users are at the top of the food chain, but 
there are users with special permissions who can create regular users, 
or modify specific parts of the documents. An example of this is a 
comments thread moderator. They need permissions to edit portions of a 
doc that doesn't belong to them. Is it proposed that I just make 
everyone an admin? How can this work for couchapps. Maybe I'm missing 
something, but I don't see that this can work at all.

_users just doesn't make sense unless all of the app capabilities get 
ripped out and CouchDB just becomes a database and nothing more. 
Otherwise, some hybrid as Jim mentions needs to happen. There is no 
reason to think that every last bit of the _user doc needs to be cached 
or in the session. This should be able to be retrieved however and 
stored where it makes sense, with the users account data.

Wendall

On 08/30/2012 10:06 AM, Jim Klo wrote:
> 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 way.
>
> 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 conductor.
> 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).
>
> Cheers,
>
> *
> *
> *
> *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 
>> <john.tigernassau@gmail.com <ma...@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 <ma...@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 <ma...@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 <ma...@gmail.com>>wrote:
>>>>>>>>>
>>>>>>>>> On Wed, Aug 29, 2012 at 9:24 PM, Dave 
>>>>>>>>> Cottlehuber<dave@muse.net.nz <ma...@muse.net.nz>>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> On 29 August 2012 08:21, Benoit Chesneau<bchesneau@gmail.com 
>>>>>>>>>>> <ma...@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 <ma...@gmail.com>
>>>>>>>>> São Paulo - SP - Brasil
>>>>>>>>>
>>>>>>>>
>>>>
>>>
>>
>>
>> -- 
>> Gabriel Mancini de Campos
>> Arquiteto de Soluções
>>
>> +55 (11) 9449-1706
>> gabriel.mancini@gmail.com <ma...@gmail.com>
>> São Paulo - SP - Brasil
>

Re: userCtx extra information

[Jim Klo <ji...@sri.com>]

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

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

Cheers,

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 <jo...@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....@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
>>>>>>> <ga...@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
>>>>>>>> <bc...@gmail.com>wrote:
>>>>>>>> 
>>>>>>>> On Wed, Aug 29, 2012 at 9:24 PM, Dave Cottlehuber<da...@muse.net.nz>
>>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> On 29 August 2012 08:21, Benoit Chesneau<bc...@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

Re: userCtx extra information

[Gabriel Mancini <ga...@gmail.com>]

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 <jo...@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....@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
>>>>>> <ga...@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
>>>>>>> <bc...@gmail.com>wrote:
>>>>>>>
>>>>>>>  On Wed, Aug 29, 2012 at 9:24 PM, Dave Cottlehuber<da...@muse.net.nz>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> On 29 August 2012 08:21, Benoit Chesneau<bc...@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

Re: userCtx extra information

["john.tiger" <jo...@gmail.com>]

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....@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
>>>>> <ga...@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
>>>>>> <bc...@gmail.com>wrote:
>>>>>>
>>>>>>> On Wed, Aug 29, 2012 at 9:24 PM, Dave Cottlehuber<da...@muse.net.nz>
>>>>>>> wrote:
>>>>>>>> On 29 August 2012 08:21, Benoit Chesneau<bc...@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
>

Re: userCtx extra information

[Robert Newson <rn...@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?
> 
> 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....@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
>>>> <ga...@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
>>>>> <bc...@gmail.com>wrote:
>>>>> 
>>>>>> On Wed, Aug 29, 2012 at 9:24 PM, Dave Cottlehuber <da...@muse.net.nz>
>>>>>> wrote:
>>>>>>> On 29 August 2012 08:21, Benoit Chesneau <bc...@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
>>> 
> 

Re: userCtx extra information

[Aliaksandr Barysiuk <a....@gmail.com>]

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....@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
>>> <ga...@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
>>>> <bc...@gmail.com>wrote:
>>>>
>>>>> On Wed, Aug 29, 2012 at 9:24 PM, Dave Cottlehuber <da...@muse.net.nz>
>>>>> wrote:
>>>>>> On 29 August 2012 08:21, Benoit Chesneau <bc...@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
>>

Re: userCtx extra information

[Benoit Chesneau <bc...@gmail.com>]

On Thu, Aug 30, 2012 at 8:22 AM, Aliaksandr Barysiuk
<a....@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
>> <ga...@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
>>> <bc...@gmail.com>wrote:
>>>
>>>> On Wed, Aug 29, 2012 at 9:24 PM, Dave Cottlehuber <da...@muse.net.nz>
>>>> wrote:
>>>>>
>>>>> On 29 August 2012 08:21, Benoit Chesneau <bc...@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
>
>

Re: userCtx extra information

[Aliaksandr Barysiuk <a....@gmail.com>]

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

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

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
> <ga...@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 <bc...@gmail.com>wrote:
>>
>>> On Wed, Aug 29, 2012 at 9:24 PM, Dave Cottlehuber <da...@muse.net.nz>
>>> wrote:
>>>> On 29 August 2012 08:21, Benoit Chesneau <bc...@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

Re: userCtx extra information

[Benoit Chesneau <bc...@gmail.com>]

On Wed, Aug 29, 2012 at 9:54 PM, Gabriel Mancini
<ga...@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 <bc...@gmail.com>wrote:
>
>> On Wed, Aug 29, 2012 at 9:24 PM, Dave Cottlehuber <da...@muse.net.nz>
>> wrote:
>> > On 29 August 2012 08:21, Benoit Chesneau <bc...@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

Re: userCtx extra information

[Gabriel Mancini <ga...@gmail.com>]

but can be nice have sume enable/disable behaviour for user

On Wed, Aug 29, 2012 at 4:39 PM, Benoit Chesneau <bc...@gmail.com>wrote:

> On Wed, Aug 29, 2012 at 9:24 PM, Dave Cottlehuber <da...@muse.net.nz>
> wrote:
> > On 29 August 2012 08:21, Benoit Chesneau <bc...@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

Re: userCtx extra information

[Benoit Chesneau <bc...@gmail.com>]

On Wed, Aug 29, 2012 at 9:24 PM, Dave Cottlehuber <da...@muse.net.nz> wrote:
> On 29 August 2012 08:21, Benoit Chesneau <bc...@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

Re: userCtx extra information

[Dave Cottlehuber <da...@muse.net.nz>]

On 29 August 2012 08:21, Benoit Chesneau <bc...@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.

A+
Dave

Re: userCtx extra information

[Benoit Chesneau <bc...@gmail.com>]

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

Re: userCtx extra information

[Aliaksandr Barysiuk <a....@gmail.com>]

We used one of the roles to store all needed information. The role can be not only string but json object also. 
Personally i do not like such solution but it is easy and works now.

Alex

On 28/08/12 20:51, john.tiger wrote:
> On 08/28/2012 10:51 AM, Robert Newson wrote:
>> the contents of session.userCtx are not customisable beyond the "name" and "roles" fields.
>
> does it make sense to have another doc type for each user that contains the extra info - then have a view that checks 
> values from both userCtx and the additional doc type ?
>
>

Re: userCtx extra information

["john.tiger" <jo...@gmail.com>]

On 08/28/2012 10:51 AM, Robert Newson wrote:
> the contents of session.userCtx are not customisable beyond the "name" and "roles" fields.

does it make sense to have another doc type for each user that contains 
the extra info - then have a view that checks values from both userCtx 
and the additional doc type ?

Re: userCtx extra information

[Robert Newson <rn...@apache.org>]

the contents of session.userCtx are not customisable beyond the "name" and "roles" fields.

On 28 Aug 2012, at 17:30, Gabriel Mancini wrote:

> I have the same question...
> 
> On Tue, Aug 28, 2012 at 7:53 AM, Aliaksandr Barysiuk
> <a....@gmail.com>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
>> 
> 
> 
> 
> -- 
> Gabriel Mancini de Campos
> Arquiteto de Soluções
> 
> +55 (11) 9449-1706
> gabriel.mancini@gmail.com
> São Paulo - SP - Brasil

Re: userCtx extra information

[Gabriel Mancini <ga...@gmail.com>]

I have the same question...

On Tue, Aug 28, 2012 at 7:53 AM, Aliaksandr Barysiuk
<a....@gmail.com>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
>



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

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