Spring Security
  1. Spring Security
  2. SEC-1557

add a getter method to DelegatingMethodSecurityMetadataSource

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Complete
    • Affects Version/s: 3.0.3
    • Fix Version/s: 3.1.0.M2, 3.0.6
    • Component/s: Core
    • Labels:
      None

      Description

      Hi,

      For the next release of Cibet control framework (www.logitags.com/cibet) I have integrated Spring Security authorization. It was possible but I had to do some 'dirty' hacks which could be avoided if Spring Security provides some very small changes:

      I exchange the DelegatingMethodSecurityMetadataSource in MethodSecurityInterceptor with an own implementation CibetDelegatingMethodSecurityMetadataSource. My implementation must work also with standard Spring Security authorization. Therefore I need to set the list of MethodSecurityMetadataSource from DelegatingMethodSecurityMetadataSource into my CibetDelegatingMethodSecurityMetadataSource.

      Problem: Not possible because getter is missing.
      Workaround: I use field access reflection on private field methodSecurityMetadataSources (dirty hack)
      Solution: add a getter to DelegatingMethodSecurityMetadataSource:

      public List getMethodSecurityMetadataSources() {
      return methodSecurityMetadataSources;
      }

        Issue Links

          Activity

          Hide
          Luke Taylor added a comment -

          It could perhaps be clearer, but the docs on global-method-security say "You can enable more than one type of annotation in the same application, but you should avoid mixing annotations types in the same interface or class to avoid confusion." The annotated types should be clearly segregated or the behaviour would not be defined. This could be useful when it becomes clear that some part of an app needs to support more complex authorization, or when using a separately created module.

          Show
          Luke Taylor added a comment - It could perhaps be clearer, but the docs on global-method-security say "You can enable more than one type of annotation in the same application, but you should avoid mixing annotations types in the same interface or class to avoid confusion." The annotated types should be clearly segregated or the behaviour would not be defined. This could be useful when it becomes clear that some part of an app needs to support more complex authorization, or when using a separately created module.
          Hide
          Wolfgang Winter added a comment -

          Release 0.8 with Spring Security integration has been released. Please check the web site.
          What do you think about my requirements for one of the next releases of Spring Security? My hacks are not very nice and I also feel not good that I am forced to have Cibet classes in the Spring Security package scope.
          best regards
          Wolfgang

          Show
          Wolfgang Winter added a comment - Release 0.8 with Spring Security integration has been released. Please check the web site. What do you think about my requirements for one of the next releases of Spring Security? My hacks are not very nice and I also feel not good that I am forced to have Cibet classes in the Spring Security package scope. best regards Wolfgang
          Hide
          Luke Taylor added a comment -

          Your requirements give us a chance to reassess some of the design choices and possibly come up with better alternatives. However, I'm never keen to just take the option which provides a fix for one use case, especially if it involves exposing framework internals which have not previously been public. Adding a getter to this class isn't a big issue, but encouraging the use of inheritance or making package-private classes public is a different matter since it encourages tighter coupling with our code and makes maintenance and modification more difficult. I'd prefer to come up with better alternatives where possible, but maintainability of the framework code will always take precedence over facilitating reuse in app code.

          Show
          Luke Taylor added a comment - Your requirements give us a chance to reassess some of the design choices and possibly come up with better alternatives. However, I'm never keen to just take the option which provides a fix for one use case, especially if it involves exposing framework internals which have not previously been public. Adding a getter to this class isn't a big issue, but encouraging the use of inheritance or making package-private classes public is a different matter since it encourages tighter coupling with our code and makes maintenance and modification more difficult. I'd prefer to come up with better alternatives where possible, but maintainability of the framework code will always take precedence over facilitating reuse in app code.
          Hide
          Wolfgang Winter added a comment -

          I understand your reluctance about inheritance and public/private. The general use case would be to allow for an easier possibility of other metadata sources as you mentioned in #1558. Maybe you have a better design idea to achieve this.

          Show
          Wolfgang Winter added a comment - I understand your reluctance about inheritance and public/private. The general use case would be to allow for an easier possibility of other metadata sources as you mentioned in #1558. Maybe you have a better design idea to achieve this.
          Hide
          Luke Taylor added a comment -

          I've added the getter method as requested.

          Show
          Luke Taylor added a comment - I've added the getter method as requested.

            People

            • Assignee:
              Luke Taylor
              Reporter:
              Wolfgang Winter
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: