Basic Auth Decode adds source to the trace

I have a proxy with the following BasicAuthentication policy

<BasicAuthentication name="Basic-Authentication">
    <DisplayName>Basic Authentication</DisplayName>
    <Operation>Decode</Operation>
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
    <User ref="private.request.header.username"/>
    <Password ref="private.request.header.password"/>
    <Source>request.header.Authorization</Source>
</BasicAuthentication>

When I trace this proxy the request.header.Authrorization variable gets added to the trace as a variable. The Authorization header is masked in the Headers section but it shows up in the variables section. I was just wondering if that is by design or if it was overlooked. I think the source for the basic auth policy should never show up in the trace. The work around for me would be to mask the field but it would be much better if this was just solved for the policy in general.

Solved Solved
0 7 705
1 ACCEPTED SOLUTION

Daniel, I've raised a ticket (b/110429629) to have this fixed.

View solution in original post

7 REPLIES 7

Hmmm, that sounds like a bug to me, Daniel. Let me look into it further.

Daniel, I've raised a ticket (b/110429629) to have this fixed.

Hey Dino, we are having the same problem, and I was wondering if this has been addressed? I can't find the bug number...

This problem was fixed back in 2018. What version of Apigee are you using?

In general when I post a bug reference, people here won't be able to directly access the bug database; that number is an internal reference. You can contact Apigee support and inquire about the status, though.

Dino, our Dev version is Version 4.50.00.00. How was the bug fixed? Is there configuration that needs to be done or does Apigee no longer add the auth header as an internal variable that becomes visible during trace?

During an assign message policy when the auth header gets set, Apigee is adding this message.header.Authorization variable to the trace and the base64 encoded auth string is getting displayed.


There is no configuration that is necessary. The fix changes the behavior of the BasicAuth policy so that it does not expose the header-to-decode. I am looking at v4.50.00 and it includes the fix in question.

During an assign message policy when the auth header gets set,

I think the situation you are describing is something different. The bug that I referenced above was: the BasicAuthentication policy was emitting trace events that exposed the Authorization header during decode or encode operations. This bug has been fixed. The fix is in OPDK v4.50.00.

You are describing something different: you are using the AssignMessage policy (not BasicAuthentication) to set a header, and you are seeing that header in trace. That is expected behavior. What you are reporting is not a bug.

To avoid exposing that information in Apigee Trace, you can do one of these two things:

  1. configure your datamask so that such sensitive data does not get emitted to trace. Here is some documentation on that which applies to Apigee X or Apigee hybrid. For OPDK, look here. The API is slightly different!
  2. Using AssignMessage to assign to request.header.Authorization, which (I think!) is already masked by default in Apigee.

Really , the first approach is best. Explicitly configure what you want to mask.

Thanks Dino, we are exploring the data mask piece. We are already doing #2 and even though it's masked in some sections, its not masked in the variables section where that internal variable is displayed, message.header.Authorization.