incubator-blur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron McCurry <amccu...@gmail.com>
Subject Re: method authorization
Date Thu, 12 Feb 2015 00:39:39 GMT
On Wednesday, February 11, 2015, Tim Williams <williamstw@gmail.com> wrote:

> On Mon, Feb 2, 2015 at 11:33 AM, Tim Williams <williamstw@gmail.com
> <javascript:;>> wrote:
> > On Mon, Feb 2, 2015 at 10:38 AM, Aaron McCurry <amccurry@gmail.com
> <javascript:;>> wrote:
> >> On Mon, Feb 2, 2015 at 10:20 AM, Tim Williams <williamstw@gmail.com
> <javascript:;>> wrote:
> >>
> >>> On Mon, Feb 2, 2015 at 8:48 AM,  <amccurry@apache.org <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
>

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