> On Jan. 21, 2016, 9:14 p.m., Bill Farner wrote: > > src/main/java/org/apache/aurora/scheduler/http/api/security/AuthorizingParam.java, > > line 34 > > <https://reviews.apache.org/r/42614/diff/1/?file=1204592#file1204592line34> > > > > The limit of 2 seems arbitrary, and this reflects in the code. Why not > > simply say that if there are multiple authorizing params, exactly one must > > be non-null?
This was a deliberate choice to address thrift param deprecation case. We currently allow only one annotation and given our backwards v-1 compatibilty story I don't really see a need for more than 2 annotations to account for migration. That said, I am fine opening it up and allow multiples as what really counts is the final argument check. > On Jan. 21, 2016, 9:14 p.m., Bill Farner wrote: > > src/main/java/org/apache/aurora/scheduler/http/api/security/ShiroAuthorizingParamInterceptor.java, > > line 210 > > <https://reviews.apache.org/r/42614/diff/1/?file=1204593#file1204593line210> > > > > Consider removing the use of guava's `Invokable` and `Parameter` > > throughout. They really only exist as an abstraction over methods and > > constructors, which we don't need here. The change is self-explanatory > > starting with > > > > ``` > > candidateMethod.getParameters() > > ``` Done. > On Jan. 21, 2016, 9:14 p.m., Bill Farner wrote: > > src/main/java/org/apache/aurora/scheduler/http/api/security/ShiroAuthorizingParamInterceptor.java, > > line 216 > > <https://reviews.apache.org/r/42614/diff/1/?file=1204593#file1204593line216> > > > > Not new, but consider dropping this check. The lookup in > > `FIELD_GETTERS_BY_TYPE` is more direct. Dropped. > On Jan. 21, 2016, 9:14 p.m., Bill Farner wrote: > > src/main/java/org/apache/aurora/scheduler/http/api/security/ShiroAuthorizingParamInterceptor.java, > > line 221 > > <https://reviews.apache.org/r/42614/diff/1/?file=1204593#file1204593line221> > > > > s/final // Done. - Maxim ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/42614/#review115697 ----------------------------------------------------------- On Jan. 21, 2016, 8:53 p.m., Maxim Khutornenko wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/42614/ > ----------------------------------------------------------- > > (Updated Jan. 21, 2016, 8:53 p.m.) > > > Review request for Aurora and Bill Farner. > > > Repository: aurora > > > Description > ------- > > We don't allow dual annotations for authorizing params in thrift. There are > cases, however, when it's needed. One example is AURORA-1583 where we would > need to support something like below before we cutoff `query` in the next > release: > ``` > Response killTasks( > @AuthorizingParam @Nullable TaskQuery query, > @Nullable Lock lock, > @AuthorizingParam @Nullable JobKey job, > int instances) throws TException; > ``` > > The new behavior allows at most 2 annotations but only one of the annotated > arguments must be non-null during interception. > > Also, added missing test coverage. > > > Diffs > ----- > > config/legacy_untested_classes.txt 6b71fd233af0d137332bc69249d16e433aa198c7 > > src/main/java/org/apache/aurora/scheduler/http/api/security/AuthorizingParam.java > 11d7e465556020571ffeefcf05596e6251ba9d19 > > src/main/java/org/apache/aurora/scheduler/http/api/security/ShiroAuthorizingParamInterceptor.java > 69056624064be4bbd4136afb4dd6e3eb33c5e0d2 > > src/test/java/org/apache/aurora/scheduler/http/api/security/ShiroAuthorizingParamInterceptorTest.java > 16a3a3b84c2a06bc340575abb58f853a8f26920d > > Diff: https://reviews.apache.org/r/42614/diff/ > > > Testing > ------- > > > Thanks, > > Maxim Khutornenko > >
