On Wednesday, February 11, 2015, Tim Williams <[email protected]> wrote:
> On Mon, Feb 2, 2015 at 11:33 AM, Tim Williams <[email protected] > <javascript:;>> wrote: > > On Mon, Feb 2, 2015 at 10:38 AM, Aaron McCurry <[email protected] > <javascript:;>> wrote: > >> On Mon, Feb 2, 2015 at 10:20 AM, Tim Williams <[email protected] > <javascript:;>> wrote: > >> > >>> On Mon, Feb 2, 2015 at 8:48 AM, <[email protected] <javascript:;>> > 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? Sounds good to me. > Thanks, > --tim >
