incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Cottlehuber <...@jsonified.com>
Subject Re: userCtx extra information
Date Thu, 30 Aug 2012 21:09:50 GMT
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ńę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

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