ExceptionCatchingModularRealmAuthorizer ?

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

ExceptionCatchingModularRealmAuthorizer ?

Brian Demers
I have a subclass of ModularRealmAuthorizer that just catches
AuthorizationException if thrown by RealmA so that RealmB gets a
chance to Authorize a user.  I found this as a result of the changes
for SHIRO-231 (which I agree with) but it broke my subclass because
now it needs a type check.

This may benefit users of the AtLeastOneSuccessfulStrategy
authentication strategy (the default).

I would like to push logic this into the ModularRealmAuthorizer
(disabled by default)

Any thoughts?
Reply | Threaded
Open this post in threaded view
|

Re: ExceptionCatchingModularRealmAuthorizer ?

kaosko
Yeah, sub-classing seems cumbersome and the use case is real, so I agree.

Kalle


On Mon, Apr 11, 2011 at 8:09 PM, Brian Demers <[hidden email]> wrote:

> I have a subclass of ModularRealmAuthorizer that just catches
> AuthorizationException if thrown by RealmA so that RealmB gets a
> chance to Authorize a user.  I found this as a result of the changes
> for SHIRO-231 (which I agree with) but it broke my subclass because
> now it needs a type check.
>
> This may benefit users of the AtLeastOneSuccessfulStrategy
> authentication strategy (the default).
>
> I would like to push logic this into the ModularRealmAuthorizer
> (disabled by default)
>
> Any thoughts?
>
Reply | Threaded
Open this post in threaded view
|

Re: ExceptionCatchingModularRealmAuthorizer ?

Les Hazlewood-2
In reply to this post by Brian Demers
Refactoring the ModularRealmAuthorizer to use the Strategy design
pattern (like the ModularRealmAuthenticator) is probably the best
approach.  This allows pluggable strategies to be used so you don't
need to subclass.

As far as SHIRO-231 is concerned, I agree with it, but I really think
we need to revert that change until 2.0.  We should not introduce
fundamental (breaking) API changes in a minor version release.  (This
is the reason for the APR versioning guidelines at least).  Thoughts?

Les
Reply | Threaded
Open this post in threaded view
|

Re: ExceptionCatchingModularRealmAuthorizer ?

Brian Demers
Yeah, changing the Realm interface defiantly violates the versioning
guidelines.  Is there anything saying the next release cannot be 2.0
(granted that doesn't change the problem here)

On the plus side, I think my ExceptionCatchingModularRealmAuthorizer
was the only think that broke, which highlights a contribution.

On Tue, Apr 12, 2011 at 2:24 PM, Les Hazlewood <[hidden email]> wrote:

> Refactoring the ModularRealmAuthorizer to use the Strategy design
> pattern (like the ModularRealmAuthenticator) is probably the best
> approach.  This allows pluggable strategies to be used so you don't
> need to subclass.
>
> As far as SHIRO-231 is concerned, I agree with it, but I really think
> we need to revert that change until 2.0.  We should not introduce
> fundamental (breaking) API changes in a minor version release.  (This
> is the reason for the APR versioning guidelines at least).  Thoughts?
>
> Les
>
Reply | Threaded
Open this post in threaded view
|

Re: ExceptionCatchingModularRealmAuthorizer ?

Les Hazlewood-2
On Thu, Apr 14, 2011 at 8:45 AM, Brian Demers <[hidden email]> wrote:
> Yeah, changing the Realm interface defiantly violates the versioning
> guidelines.  Is there anything saying the next release cannot be 2.0
> (granted that doesn't change the problem here)

Nope, nothing that says that, but 2.0 is probably a large enough scope
that it means we won't have a release in a long time.  I'd rather not
hold off what could be 6 to 9 months before getting our next release
out.  IMO that's a stifling thing to do for a community that is
currently picking up a huge amount of steam (~ %20 traffic increase
compounded per month)

Here is some of the stuff discussed for version 2:

https://cwiki.apache.org/confluence/display/SHIRO/Version+2+Brainstorming

Please feel free to add your own ideas!

> On the plus side, I think my ExceptionCatchingModularRealmAuthorizer
> was the only think that broke, which highlights a contribution.

Yep, but we have no idea how many other custom Authorizer
implementations there are.  That could leave a bad taste in the mouths
of those people - not something I'd like to risk.

It is very important to me that, as a security framework, we create
releases with stability and consistency in mind, especially now that
we're past 1.0.

My .02,

Les
Reply | Threaded
Open this post in threaded view
|

Re: ExceptionCatchingModularRealmAuthorizer ?

Brian Demers
Agreed.

Maybe we should revert the changes, then deprecate the methods in the
Realm interface.  That _may_ give people a heads up. and in the 2.0 we
pull them out.  I not 100% sure that would have the desired effect
without seeing how the deprecation errors would propagate across the
source.




On Thu, Apr 14, 2011 at 2:22 PM, Les Hazlewood <[hidden email]> wrote:

> On Thu, Apr 14, 2011 at 8:45 AM, Brian Demers <[hidden email]> wrote:
>> Yeah, changing the Realm interface defiantly violates the versioning
>> guidelines.  Is there anything saying the next release cannot be 2.0
>> (granted that doesn't change the problem here)
>
> Nope, nothing that says that, but 2.0 is probably a large enough scope
> that it means we won't have a release in a long time.  I'd rather not
> hold off what could be 6 to 9 months before getting our next release
> out.  IMO that's a stifling thing to do for a community that is
> currently picking up a huge amount of steam (~ %20 traffic increase
> compounded per month)
>
> Here is some of the stuff discussed for version 2:
>
> https://cwiki.apache.org/confluence/display/SHIRO/Version+2+Brainstorming
>
> Please feel free to add your own ideas!
>
>> On the plus side, I think my ExceptionCatchingModularRealmAuthorizer
>> was the only think that broke, which highlights a contribution.
>
> Yep, but we have no idea how many other custom Authorizer
> implementations there are.  That could leave a bad taste in the mouths
> of those people - not something I'd like to risk.
>
> It is very important to me that, as a security framework, we create
> releases with stability and consistency in mind, especially now that
> we're past 1.0.
>
> My .02,
>
> Les
>
Reply | Threaded
Open this post in threaded view
|

Re: ExceptionCatchingModularRealmAuthorizer ?

Les Hazlewood-2
Yeah, I personally would feel a lot more comfortable with this.  I
think the best way to go about doing this is deprecate them as you
said and then also create a Jira issue to ensure that it is visible
when we release 2.0.  From the Jira issues, we can create a 'what's
changed in 2.0' documentation page that will make these things very
clear.

Les

On Fri, Apr 15, 2011 at 7:30 AM, Brian Demers <[hidden email]> wrote:

> Agreed.
>
> Maybe we should revert the changes, then deprecate the methods in the
> Realm interface.  That _may_ give people a heads up. and in the 2.0 we
> pull them out.  I not 100% sure that would have the desired effect
> without seeing how the deprecation errors would propagate across the
> source.
>
>
>
>
> On Thu, Apr 14, 2011 at 2:22 PM, Les Hazlewood <[hidden email]> wrote:
>> On Thu, Apr 14, 2011 at 8:45 AM, Brian Demers <[hidden email]> wrote:
>>> Yeah, changing the Realm interface defiantly violates the versioning
>>> guidelines.  Is there anything saying the next release cannot be 2.0
>>> (granted that doesn't change the problem here)
>>
>> Nope, nothing that says that, but 2.0 is probably a large enough scope
>> that it means we won't have a release in a long time.  I'd rather not
>> hold off what could be 6 to 9 months before getting our next release
>> out.  IMO that's a stifling thing to do for a community that is
>> currently picking up a huge amount of steam (~ %20 traffic increase
>> compounded per month)
>>
>> Here is some of the stuff discussed for version 2:
>>
>> https://cwiki.apache.org/confluence/display/SHIRO/Version+2+Brainstorming
>>
>> Please feel free to add your own ideas!
>>
>>> On the plus side, I think my ExceptionCatchingModularRealmAuthorizer
>>> was the only think that broke, which highlights a contribution.
>>
>> Yep, but we have no idea how many other custom Authorizer
>> implementations there are.  That could leave a bad taste in the mouths
>> of those people - not something I'd like to risk.
>>
>> It is very important to me that, as a security framework, we create
>> releases with stability and consistency in mind, especially now that
>> we're past 1.0.
>>
>> My .02,
>>
>> Les
Reply | Threaded
Open this post in threaded view
|

Re: ExceptionCatchingModularRealmAuthorizer ?

Brian Demers
For future googlers the ExceptionCatchingModularRealmAuthorizer bits are
tracked by: https://issues.apache.org/jira/browse/SHIRO-348

On Fri, Apr 15, 2011 at 1:55 PM, Les Hazlewood <[hidden email]>wrote:

> Yeah, I personally would feel a lot more comfortable with this.  I
> think the best way to go about doing this is deprecate them as you
> said and then also create a Jira issue to ensure that it is visible
> when we release 2.0.  From the Jira issues, we can create a 'what's
> changed in 2.0' documentation page that will make these things very
> clear.
>
> Les
>
> On Fri, Apr 15, 2011 at 7:30 AM, Brian Demers <[hidden email]>
> wrote:
> > Agreed.
> >
> > Maybe we should revert the changes, then deprecate the methods in the
> > Realm interface.  That _may_ give people a heads up. and in the 2.0 we
> > pull them out.  I not 100% sure that would have the desired effect
> > without seeing how the deprecation errors would propagate across the
> > source.
> >
> >
> >
> >
> > On Thu, Apr 14, 2011 at 2:22 PM, Les Hazlewood <[hidden email]>
> wrote:
> >> On Thu, Apr 14, 2011 at 8:45 AM, Brian Demers <[hidden email]>
> wrote:
> >>> Yeah, changing the Realm interface defiantly violates the versioning
> >>> guidelines.  Is there anything saying the next release cannot be 2.0
> >>> (granted that doesn't change the problem here)
> >>
> >> Nope, nothing that says that, but 2.0 is probably a large enough scope
> >> that it means we won't have a release in a long time.  I'd rather not
> >> hold off what could be 6 to 9 months before getting our next release
> >> out.  IMO that's a stifling thing to do for a community that is
> >> currently picking up a huge amount of steam (~ %20 traffic increase
> >> compounded per month)
> >>
> >> Here is some of the stuff discussed for version 2:
> >>
> >>
> https://cwiki.apache.org/confluence/display/SHIRO/Version+2+Brainstorming
> >>
> >> Please feel free to add your own ideas!
> >>
> >>> On the plus side, I think my ExceptionCatchingModularRealmAuthorizer
> >>> was the only think that broke, which highlights a contribution.
> >>
> >> Yep, but we have no idea how many other custom Authorizer
> >> implementations there are.  That could leave a bad taste in the mouths
> >> of those people - not something I'd like to risk.
> >>
> >> It is very important to me that, as a security framework, we create
> >> releases with stability and consistency in mind, especially now that
> >> we're past 1.0.
> >>
> >> My .02,
> >>
> >> Les
>