hk2
  1. hk2
  2. HK2-115

HK2 to be able to supply the Injectee stack (chain of injectees)

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 2.2.0
    • Fix Version/s: 2.4.0
    • Component/s: None
    • Labels:
      None

      Description

      In the HK2 filter and validation, the Validator.validate(ValidationInformation info) can get the injectee by using info.getInjectee().

      In the above, only the one injectee is obtained. Sometime, we need to get the injectee chain (.e., injectee's injectee, ...), and use the injectee chain to decide the privilege of the codes to decide if the caller's code is allowed to access the protected resource or not.

      Similar like the Injectee, we wish to get the class which did the service lookup, you can call this something like lookuper.

      It is also possible that a service instance is retrieved by a chain of mixed injectee and lookuper, e.g., injectee1 --> lookuper1 --> lookuper2 ---> injectee2 --> .... --> myserviceInstance

      It would be nice such a chain can be found by doing injectee/lookuper.getParent() calls.

        Activity

        Hide
        jwells added a comment -

        I am a little concerned about this for a few reasons.

        Consider the following use case:

        @Singleton
        public class Bar

        { @Inject private ProtectedService ps; }

        @PerLookup
        public class Foo

        { @Inject private Bar bar; }

        In this use case, you are trying to prevent Foo from being allowed to inject Bar, because Bar has access to the ProtectedService. However, since Bar is a Singleton, it will only be created once, possibly in the lookup for Foo, but possibly prior to the lookup for Foo. So your validation code will not work here if Bar was created prior to the lookup for Foo.

        I think instead what you are asking for is complete knowledge of every descriptor that went into creating every injection point for every object (remember that there could be many instances of a PerLookup service in the system). This is information that HK2 does not keep at the moment.

        You may be able to get a partial indication of the descriptors being used by following a chain from the "getInjectees" field of the ValidationInformation.getCandidate ActiveDescriptor. Assuming there have been no dynamic changes or changes in ranking, you could get some idea of which descriptors were used to create every object that might be touched. However, it is not perfect and for that reason I'd think it was suspect.

        Furthermore, consider this alternative implementation of Bar:

        @Singleton
        public class Bar {
        private final ProtectedService ps;

        @Inject
        private Bar(ServiceLocator locator)

        { ps = locator.getService(ProtectedService.class); }

        }

        In this case, Bar has a ProtectedService and uses it just as before but the idea of having the entire stack of injected things will not work here, since ProtectedService was not in fact directly injected, but was looked up in the constructor of Bar.

        So I think there are many holes in this use case that we need to think about...

        I also wonder if this isn't the sort of thing that should be protected by the normal java code protection scheme. Like, if Foo shouldn't be allowed to access ProtectedService (and assuming that Bar does NOT do a doPriv) then although HK2 wouldn't help you out here by catching it earlier, at least the Java permissions would not allow the code of Foo to operate on ProtectedService. Although usually if there is a ProtectedService that is going through some trusted code (Bar) it is generally the responsibility of Bar to ensure it protects that service properly...

        Show
        jwells added a comment - I am a little concerned about this for a few reasons. Consider the following use case: @Singleton public class Bar { @Inject private ProtectedService ps; } @PerLookup public class Foo { @Inject private Bar bar; } In this use case, you are trying to prevent Foo from being allowed to inject Bar, because Bar has access to the ProtectedService. However, since Bar is a Singleton, it will only be created once, possibly in the lookup for Foo, but possibly prior to the lookup for Foo. So your validation code will not work here if Bar was created prior to the lookup for Foo. I think instead what you are asking for is complete knowledge of every descriptor that went into creating every injection point for every object (remember that there could be many instances of a PerLookup service in the system). This is information that HK2 does not keep at the moment. You may be able to get a partial indication of the descriptors being used by following a chain from the "getInjectees" field of the ValidationInformation.getCandidate ActiveDescriptor. Assuming there have been no dynamic changes or changes in ranking, you could get some idea of which descriptors were used to create every object that might be touched. However, it is not perfect and for that reason I'd think it was suspect. Furthermore, consider this alternative implementation of Bar: @Singleton public class Bar { private final ProtectedService ps; @Inject private Bar(ServiceLocator locator) { ps = locator.getService(ProtectedService.class); } } In this case, Bar has a ProtectedService and uses it just as before but the idea of having the entire stack of injected things will not work here, since ProtectedService was not in fact directly injected, but was looked up in the constructor of Bar. So I think there are many holes in this use case that we need to think about... I also wonder if this isn't the sort of thing that should be protected by the normal java code protection scheme. Like, if Foo shouldn't be allowed to access ProtectedService (and assuming that Bar does NOT do a doPriv) then although HK2 wouldn't help you out here by catching it earlier, at least the Java permissions would not allow the code of Foo to operate on ProtectedService. Although usually if there is a ProtectedService that is going through some trusted code (Bar) it is generally the responsibility of Bar to ensure it protects that service properly...
        Hide
        jwells added a comment -

        We will defer work on this one until we can work out the use cases more fully. It is possible that a better solution for the real problem is to use Proxiable scopes.

        Show
        jwells added a comment - We will defer work on this one until we can work out the use cases more fully. It is possible that a better solution for the real problem is to use Proxiable scopes.

          People

          • Assignee:
            jwells
            Reporter:
            spei
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: