Where to see Issue details from Apigee Edge Release notes

sgarg24
Participant II

Where can we see the details regarding Bug fixes listed in Apigee Edge Piblic cloud release notes?

Ref Link: https://docs.apigee.com/release/notes/180302-apigee-edge-public-cloud-release-notes

We want to understand what is fixed as part of below issue :

67785822API RuntimeMask configuration not hiding sensitive data in trace
Solved Solved
1 5 165
1 ACCEPTED SOLUTION

Generally we do not publish details beyond the brief summary you can see in the Release Notes.

But, I can tell you about 67785822.

Sorry for the long story; the issue was a bit subtle.

Previous to February 2018, When an API Proxy used AssignMessage to implicitly assign a message , there was no information emitted to the Trace session. If the message included sensitive information, such as an authorization header containing a secret, or some other sensitive data, there was never any chance that this information would be visible in a trace output.

In February 2018, Apigee made an improvement to the AssignMessage behavior, so that there would be "Set Variable" entries in the trace, for each constituent part of the message being assigned. For example if you had something like this:

<AssignMessage name='AM-1'>
  <AssignTo createNew='true' transport='http' type='request'>myMsg</AssignTo>
  <Set> 
    <Headers>
      <Header name='foo'>bar</Header>
    </Headers>
    <Verb>GET</Verb>
  </Set>
</AssignMessage>

...then IF there was an active trace session when that policy was executing, you would see in the trace output, entries for

myMsg.header.foo = bar

myMsg.header.verb = GET

But this is not a bug - this is new, desired behavior. We think it makes it nicer on policy designers. So one aspect of bug 67785822 was to simply educate customers that they'd need to add trace masks for any message object that was assigned with the AssignMessage policy. We enhanced the documentation to state that.

But there IS actually a bug; what was it?

It relates to the ServiceCallout policy. With ServiceCallout, it is possible to specify a request directly in the configuration, like this:

<ServiceCallout name='SC-1'>
  <Request>
    <Set>
     <Headers>
       <Header name='content-type'>application/x-www-form-urlencoded</Header>
     </Headers>
     <FormParams>
       <FormParam name='username'>{private.username}</FormParam>
       <FormParam name='password'>{private.password}</FormParam>
     </FormParams>
     <Verb>POST</Verb>
    </Set>
  </Request>
   ...

You will see that under the Request element, this is the same configuration syntax as AssignMessage. In fact ServiceCallout wraps the AssignMessage behavior in this case. But note here, that there is no name specified for the request message. ServiceCallout allows that, when the proxy designer doesn't care to explicitly name the request message being assigned. So what variable names appear in Trace in this case? They were:

null.header.content-type = application/x-www-form-urlencoded

null.formparam.username = dino@apigee.com

...and so on. This was not ideal. Also this behavior was not documented.

The fix here was 2-fold:

  1. use "servicecallout.request" as the implicit name of the variable being assigned, when no name is explicitly given in the Request element.

    Now, the trace output will include entries like this:

    servicecallout.request.header.content-type = application/x-www-form-urlencoded

    servicecallout.request.formparam.username = dino@apigee.com

  2. document that behavior, so that people know to set trace masks for "servicecallout.request.header.Authorization" and so on.

View solution in original post

5 REPLIES 5

Generally we do not publish details beyond the brief summary you can see in the Release Notes.

But, I can tell you about 67785822.

Sorry for the long story; the issue was a bit subtle.

Previous to February 2018, When an API Proxy used AssignMessage to implicitly assign a message , there was no information emitted to the Trace session. If the message included sensitive information, such as an authorization header containing a secret, or some other sensitive data, there was never any chance that this information would be visible in a trace output.

In February 2018, Apigee made an improvement to the AssignMessage behavior, so that there would be "Set Variable" entries in the trace, for each constituent part of the message being assigned. For example if you had something like this:

<AssignMessage name='AM-1'>
  <AssignTo createNew='true' transport='http' type='request'>myMsg</AssignTo>
  <Set> 
    <Headers>
      <Header name='foo'>bar</Header>
    </Headers>
    <Verb>GET</Verb>
  </Set>
</AssignMessage>

...then IF there was an active trace session when that policy was executing, you would see in the trace output, entries for

myMsg.header.foo = bar

myMsg.header.verb = GET

But this is not a bug - this is new, desired behavior. We think it makes it nicer on policy designers. So one aspect of bug 67785822 was to simply educate customers that they'd need to add trace masks for any message object that was assigned with the AssignMessage policy. We enhanced the documentation to state that.

But there IS actually a bug; what was it?

It relates to the ServiceCallout policy. With ServiceCallout, it is possible to specify a request directly in the configuration, like this:

<ServiceCallout name='SC-1'>
  <Request>
    <Set>
     <Headers>
       <Header name='content-type'>application/x-www-form-urlencoded</Header>
     </Headers>
     <FormParams>
       <FormParam name='username'>{private.username}</FormParam>
       <FormParam name='password'>{private.password}</FormParam>
     </FormParams>
     <Verb>POST</Verb>
    </Set>
  </Request>
   ...

You will see that under the Request element, this is the same configuration syntax as AssignMessage. In fact ServiceCallout wraps the AssignMessage behavior in this case. But note here, that there is no name specified for the request message. ServiceCallout allows that, when the proxy designer doesn't care to explicitly name the request message being assigned. So what variable names appear in Trace in this case? They were:

null.header.content-type = application/x-www-form-urlencoded

null.formparam.username = dino@apigee.com

...and so on. This was not ideal. Also this behavior was not documented.

The fix here was 2-fold:

  1. use "servicecallout.request" as the implicit name of the variable being assigned, when no name is explicitly given in the Request element.

    Now, the trace output will include entries like this:

    servicecallout.request.header.content-type = application/x-www-form-urlencoded

    servicecallout.request.formparam.username = dino@apigee.com

  2. document that behavior, so that people know to set trace masks for "servicecallout.request.header.Authorization" and so on.

@wwitman @willwitman - just FYI for b/67785822 and b/73256558

Thanks a lot @Dino for explaining the issue fixed here.

Just to inform the group that there are other issues with Assign Message policy and data masking feature. We had already raised Support ticket for same and was told that it is by design. Our intention with this question was to understand if bug fix from release notes, is related to same issue.

If we use <Set> <Payload> in a AssignMessage policy and copy request payload, for some reason, we get two variables listed in trace:
1) request.content

2) message.content

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<AssignMessage async="false" continueOnError="false" enabled="true" name="Build-new-request">
    <DisplayName>Build-new-request</DisplayName>
    <Properties/>
    <Set>
        <Payload contentType="application/json" variablePrefix="@" variableSuffix="#">
            @request.content#
        </Payload>
    </Set>
    <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
    <AssignTo createNew="true" transport="http" type="request"/>
</AssignMessage>

Masking these variables are not really useful, as already stated in documentation. It forces full masking on request and response body across trace session.

Just wondering if apigee team will ever find a solution to allow specific field level masking in message.content variable or maybe remove this variable completely.

From Dino's clarification of the bugfix, we realized that if we add explicit name to AssignTo variable, the "message.content" variable is not listed in trace session. We will try to analyze this further.

yes, the reason you see "message.content" in the Trace output is that you are implicitly assigning to "message" when your AssignTo element is empty.

The reason you see "request.content' in the trace output is that you are explicitly READING that variable when you refer to it in the Payload element of the AssignMessage policy.

In either case you can add these variables to the masked variables.

Today there is no possibility to mask specific fields within the message content. However, you may want to explore the Google DLP API which can do exactly that. What you could do is:

  1. mask request.content
  2. ServiceCallout to Google DLP API with request.content
  3. receive reply - and trace THAT