Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <503FCF95.4070908@83864.com>
References: <503CA33A.6080305@gmail.com>
	<CAJNb-9qEAr7tk4K5EPEcuM5RVxpS0iYSbo3QV49epoYXHs6WtA@mail.gmail.com>
	<CAHZBNKb4K0oatL-i-0SVN2W=xoGF1LijqCcR4Si6_-CdVSxBbg@mail.gmail.com>
	<CAJNb-9rXVM7vkZgK0=hErJ-BSuHzGp5r9mzkMJd8ryebLJqo8Q@mail.gmail.com>
	<CAKNVnzycMA7N7w9jNgiAC6O-rj34F66J=28m1gt-0a8_AcTuew@mail.gmail.com>
	<CAJNb-9oT5s7T3cfnggN5nU6neT8rKyLe33Ay_bR==+8kCPDkig@mail.gmail.com>
	<503F06B4.8010303@gmail.com>
	<CAJNb-9rU+dfe6Ehohxtu0rfjRFRr7S3MQre731SFKo163JqGzQ@mail.gmail.com>
	<503F4934.3010007@gmail.com>
	<EBE58485-DF28-45AB-9168-856EB4ABD213@apache.org>
	<503F592D.2000208@gmail.com>
	<CAKNVnzyxgSJ22bAHwO-B9Oee8xeEyCaA31h2kWUbWoaVj4ZNgg@mail.gmail.com>
	<8B6A2452-D9B7-4F1D-80A3-40E5170171DC@sri.com>
	<503FB309.4050908@83864.com>
	<CAJNb-9qsfviWkb3jU5YjRccTwg3Du2zsTMEkobf3-xaAprhbCQ@mail.gmail.com>
	<503FCF95.4070908@83864.com>
Date: Thu, 30 Aug 2012 23:09:50 +0200
Message-ID: 
 <CAL+Y1nuLusfbEXikff8zHgA=rEkmd5M3Wa+XT0Zs3mM_weLJnQ@mail.gmail.com>
Subject: Re: userCtx extra information
From: Dave Cottlehuber <dch@jsonified.com>
To: user@couchdb.apache.org
Content-Type: multipart/alternative; boundary=20cf3074d2fa8dca4f04c88218de

--20cf3074d2fa8dca4f04c88218de
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 30 August 2012 22:39, Wendall Cada <wendallc@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=C4=ABt
>>
>>  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 designe=
d
> 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=3Dtrue to pull in the linked
doc.

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

A+
Dave

--20cf3074d2fa8dca4f04c88218de--