On Fri, Feb 12, 2010 at 7:10 AM, Chris Anderson jch...@apache.org wrote:
On Tue, Feb 9, 2010 at 2:52 PM, Chris Anderson jch...@apache.org wrote:
Devs,
I've been getting a lot of feedback about the authentication
authorization work that I did over the holidays and over the last few
weeks.
Benoit,
The .ini file suggestion seems a good idea, as it allows for pluggable
password hash validation. Now we're thinking about OpenLDAP schemes, but
tomorrow someone might suggest or require something else.
About the JSON object, containing the hash scheme in an attribute and the
hash in a
I think what you say has merit, but it doesn't jibe with my
understanding of our implementation in a logical way. I'm ready to
ship the basic programming model we have - it maps cleanly onto the
underlying infrastructure (less abstraction can be a good thing).
With respect, I think we're
On Thu, Feb 11, 2010 at 4:20 AM, Brian Candler b.cand...@pobox.com wrote:
I think what you say has merit, but it doesn't jibe with my
understanding of our implementation in a logical way. I'm ready to
ship the basic programming model we have - it maps cleanly onto the
underlying infrastructure
On Thu, Feb 11, 2010 at 08:32:49AM -0800, Chris Anderson wrote:
To be clear, I'm not suggesting this at all.
It'd be more like (pardon my earlier accidental _underscores):
{
readers:{
names:[foo,bar],
roles:[baz, _replicator, doctor]
},
admins:{
On Tue, Feb 9, 2010 at 2:52 PM, Chris Anderson jch...@apache.org wrote:
Devs,
I've been getting a lot of feedback about the authentication
authorization work that I did over the holidays and over the last few
weeks. There are also some enhancements I've been thinking about for a
while.
On 11 Feb 2010, at 22:10, Chris Anderson wrote:
2) ACLs / Security Object
I couldn't originally think of a reason the validation funs would need
to see the per-db admins / readers lists. Brian has a use case for
this. Also, I think I can accomplish this feature while also
simplifying the
On Wed, Feb 10, 2010 at 12:24:26AM +0100, Benoit Chesneau wrote:
I've read all the thread, and I'm not conviced all readers and admins
should be in one doc. List could be long also it would require to
check if one already exists some stuff like it. Why not putting all in
their docs and making
On Wed, Feb 10, 2010 at 2:12 AM, Brian Candler b.cand...@pobox.com wrote:
On Wed, Feb 10, 2010 at 12:24:26AM +0100, Benoit Chesneau wrote:
I've read all the thread, and I'm not conviced all readers and admins
should be in one doc. List could be long also it would require to
check if one
On Wed, Feb 10, 2010 at 2:27 PM, Brian Candler b.cand...@pobox.com wrote:
On Wed, Feb 10, 2010 at 07:26:00AM -0800, Chris Anderson wrote:
The problem with this approach, imho, is that currently users have the
same set of roles in every db. That is, your userCtx doesn't change
depending on the
Devs,
I've been getting a lot of feedback about the authentication
authorization work that I did over the holidays and over the last few
weeks. There are also some enhancements I've been thinking about for a
while. Here's a quick list of what I see as the important things to
do. I'm not
11 matches
Mail list logo
