incubator-blur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Williams <william...@gmail.com>
Subject Re: method authorization
Date Thu, 12 Feb 2015 00:36:27 GMT
On Mon, Feb 2, 2015 at 11:33 AM, Tim Williams <williamstw@gmail.com> wrote:
> On Mon, Feb 2, 2015 at 10:38 AM, Aaron McCurry <amccurry@gmail.com> wrote:
>> On Mon, Feb 2, 2015 at 10:20 AM, Tim Williams <williamstw@gmail.com> wrote:
>>
>>> On Mon, Feb 2, 2015 at 8:48 AM,  <amccurry@apache.org> wrote:
>>> > Repository: incubator-blur
>>> > Updated Branches:
>>> >   refs/heads/master 0c04e4e6a -> 4468f6cc5
>>> >
>>> >
>>> > Adding api to handle securing method calls by user and/or ipaddress.
>>> This should allow for controlling access to actions, tables, commands, etc.
>>> >
>>>
>>> <snipped>
>>>
>>> >    public static final String BLUR_SECURITY_SASL_TYPE =
>>> "blur.security.sasl.type";
>>> >    public static final String BLUR_SECURITY_SASL_ENABLED =
>>> "blur.security.sasl.enabled";
>>> > +  public static final String BLUR_CONTROLLER_SERVER_SECURITY_CLASS =
>>> "blur.controller.server.security.class";
>>> > +  public static final String BLUR_SHARD_SERVER_SECURITY_CLASS =
>>> "blur.shard.server.security.class";
>>>
>>> What's the scenario for having these independently configurable? Seems
>>> like we introduce opportunity for misconfiguration to what benefit?
>>>
>>
>> Yes I see your point.  However if someone had a valid reason for running
>> different security version depending on the server type currently they
>> would be left with having to define two different blur-site files one for
>> each type of server.
>>
>> I suppose that we could pass the server type into the constructor for the
>> security class and that could achieve the same behavior.
>>
>> Thoughts?
>
> Maybe instead of instances, it's a factory class where you're handed
> the server context (e.g. ServerContext.Shard)? This would force
> implementor's to deal with it and eliminate the potential for
> misconfiguration.
>
> Additionally, what do you think about evolving it to being more of a
> FilterChain-style so that discrete Filter's could be chained together
> to form the overall request authorization.

The more I think about it, the more I like this approach if no one's
against moving to a FilterChain-style approach I think I'll give it a
go.  I think it'd also be handy if individual filters could add
attributes to a map of attributes which other filters could use to
make decisions?

Thanks,
--tim

Mime
View raw message