On Mon, Feb 2, 2015 at 11:33 AM, Tim Williams <[email protected]> wrote: > On Mon, Feb 2, 2015 at 10:38 AM, Aaron McCurry <[email protected]> wrote: >> On Mon, Feb 2, 2015 at 10:20 AM, Tim Williams <[email protected]> wrote: >> >>> On Mon, Feb 2, 2015 at 8:48 AM, <[email protected]> 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
