OFBiz
  1. OFBiz
  2. OFBIZ-3699

ServiceDispatcher.checkAuth modifies the context if the invocation service has a permissionServiceName

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: Trunk
    • Fix Version/s: None
    • Component/s: framework
    • Labels:
      None

      Description

      Created as a result of thread: http://n4.nabble.com/Magically-converted-types-from-simpleTypeConvert-td1838891.html

      The follow code in the ServiceDispatcher ...

      if (UtilValidate.isNotEmpty(origService.permissionServiceName)) {
      ...
      if (hasPermission.booleanValue()) {
      context.putAll(permResp);
      context = origService.makeValid(context, ModelService.IN_PARAM);

      ... causes the incoming context to be modified both by adding values from the results of the permission service but also by converting any datatypes to match those in the service definition. This hides any invalid service invocations (from a data type pov) and if the permisionServiceName is removed, the code would start failing with the incorrect data types.

      Suggest is to change this to something like ...

      Map<String, Object> permRespContext = ServiceUtil.setServiceFields(dctx, serviceName, permResp);
      context.putAll(permRespContext);

      The concern is that by doing this there may be some services that were relying on the data type conversion (because they were invalid requests) which would start to fail. Appropriate impact analysis of services that define "permissionServiceName" and appropriate resolutions need to be included with this change.

        Activity

        Bob Morley created issue -
        Hide
        Scott Gray added a comment -

        I had a go at fixing this over the weekend but the unit tests fail because we already have code that is passing invalid parameters to service calls. What I would like to do is fix the bug before any more damage is done and just disable the offending unit tests until they can be corrected.
        Committing the fix will most likely expose new bugs in the regular code but there isn't really much we can do to avoid that IMO.

        Show
        Scott Gray added a comment - I had a go at fixing this over the weekend but the unit tests fail because we already have code that is passing invalid parameters to service calls. What I would like to do is fix the bug before any more damage is done and just disable the offending unit tests until they can be corrected. Committing the fix will most likely expose new bugs in the regular code but there isn't really much we can do to avoid that IMO.
        Hide
        Bob Morley added a comment -

        Yes I think that was my original concern. What you probably can not do (very easily) is find all of the actual production code that is passing invalid parameters. I agree we should get this in before any more damage is done, but I think we need to understand that this will spawn a number of "invalid service invocation" tickets.

        I originally came across this with creation of a ProductionRun as indicated in the referenced thread. That is one spot where we will start to break with this fix. Should we create a single parent ticket where all of the instances of failure can be recorded and we can resolve them piecemeal?

        Show
        Bob Morley added a comment - Yes I think that was my original concern. What you probably can not do (very easily) is find all of the actual production code that is passing invalid parameters. I agree we should get this in before any more damage is done, but I think we need to understand that this will spawn a number of "invalid service invocation" tickets. I originally came across this with creation of a ProductionRun as indicated in the referenced thread. That is one spot where we will start to break with this fix. Should we create a single parent ticket where all of the instances of failure can be recorded and we can resolve them piecemeal?
        Hide
        Adrian Crum added a comment -

        If I understand correctly, there are two issues mentioned here:

        1. Results from the permission service are added to the service parameters.
        2. Service IN parameter data types are converted before invoking the service.

        If that is correct, then #2 is not an issue - that is the intended behavior. For example, if HTTP parameters are passed to a service, then all of them will be java.lang.String data types (or a List of Strings). So, the automatic data type conversion is needed.

        Show
        Adrian Crum added a comment - If I understand correctly, there are two issues mentioned here: 1. Results from the permission service are added to the service parameters. 2. Service IN parameter data types are converted before invoking the service. If that is correct, then #2 is not an issue - that is the intended behavior. For example, if HTTP parameters are passed to a service, then all of them will be java.lang.String data types (or a List of Strings). So, the automatic data type conversion is needed.
        Jacopo Cappellato made changes -
        Field Original Value New Value
        Fix Version/s Trunk [ 12311928 ]

          People

          • Assignee:
            Unassigned
            Reporter:
            Bob Morley
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:

              Development