I see. Would it rather make sense to hide "shiro-or-else" decision
behind a light interface instead? Something along the lines of the
existing SessionValidator.checkAuthorized() that would accept a
wrapper object with all necessary security data.
On Wed, Feb 11, 2015 at 4:20 PM, Kevin Sweeney wro
I'm proposing more-or-less the "if
SHIRO_ENABLED do shiro_auth else do old_stuff" approach so that the
SHIRO_ENABLED branch can throw UnsupportedOperationException for a period
of time.
On Wed, Feb 11, 2015 at 4:14 PM, Maxim Khutornenko wrote:
> Right, I was asking about an example of the interi
Right, I was asking about an example of the interim incremental
approach you are proposing. Are you envisioning something like "if
SHIRO_ENABLED do shiro_auth else do old_stuff" approach? The example
you gave shows the end result not what we will see in 0.8.0 (unless
you are suggesting moving "old_
I think that would be too big a patch to land all at once. I'd like to add
in Shiro permission checks and annotations incrementally behind this flag
as there are conceptually different changes that will benefit from small
reviews. If I take the approach of ripping out the current framework first
we
Sounds good!
On Wed, Feb 11, 2015 at 3:57 PM, Kevin Sweeney wrote:
> I'm thinking that flag will control which Guice bindings are applied, so
> there would be 2 parallel implementations for a bit. This would necessitate
> factoring out capabilityValidator calls to a decorator class (or risk
> ha
Any example? The original code fragment suggest our current security
model does not map cleanly into shiro. I am +1 on the first pass to
reduce the "if-else" ugliness if possible.
On Wed, Feb 11, 2015 at 3:57 PM, Kevin Sweeney wrote:
> I'm thinking that flag will control which Guice bindings are
I'm thinking that flag will control which Guice bindings are applied, so
there would be 2 parallel implementations for a bit. This would necessitate
factoring out capabilityValidator calls to a decorator class (or risk
having #ifdef-like logic everywhere in SchedulerThriftInterface).
On Wed, Feb 1
How do you envision things looking in the intermediate phase where we have
support for both security modes?
I imagine it's easy enough on the Shiro side of if we go with the AOP
annotations for authorization (the interceptor can just check if
security_mode == SHIRO before doing anything), but that
On Wed, Feb 11, 2015 at 3:19 PM, Zameer Manji wrote:
> +1 to this proposal.
>
> Will we have dual implementations of API methods as we deprecate the
> SessionKey based API methods?
>
Yes for backwards-compatibility I think we'll need a flag to indicate which
system to use. It will probably be an
+1 to this proposal.
Will we have dual implementations of API methods as we deprecate the
SessionKey based API methods?
On Wed, Feb 11, 2015 at 3:13 PM, Kevin Sweeney wrote:
> I've been thinking about revamping the authentication and authorization in
> the scheduler recently. I've investigated
10 matches
Mail list logo
