Extend requestWhitelist and requestBlacklist with nested keys

[bithavoc]

Extend requestWhitelist and requestBlacklist with nested keys

[floatingLomas]

That'd be cool - why don't you fork it, do it, and submit a pull request. :)

[mbonig]

Did this ever happen?

[mbonig]

So, with the current version, this process can be supported pretty easily with lodash:

requestFilter: function (originalObj, propName) {
            return _.get(originalObj, propName);
        }

[rosston]

@mbonig Looks like you figured out it didn't happen. 😃 Your solution (thanks for posting it!) certainly makes it easy for someone to do it themselves in their app.

I've been swamped recently, but I'll try to take a stab at getting this (and #62) supported by default soon. It's not quite as easy as just using _.get in the module though, since user-provided requestFilter and responseFilter should probably get called with the top level object (presumably already trimmed to the specified sub-properties). Sorry, talking myself through it right here. I think I just described the only complexity.

[hasancansaral]

...
requestFilter: function (req, propName) {
    return (
        propName == 'user' ?
            req[propName]['email'] :
            req[propName]
    );
  },
...

did the trick for me. Actually, the documentation could mention this usage a bit more. I'll fork it and open a PR asap. Maybe this issue can be Closed?

[rosston]

Indeed, that is an easy solution that anyone can do themselves. And thank you for noting it! But it's not quite as easy as

...
requestWhitelist: ['user.email']
...

I know it's been a month since I said I'd work on it, but I swear I really do plan on working on it soon. I'm just often swamped!

[rosston]

Sorry! I wasn't clear. My snippet is what I want the usage to be like. I haven't implemented it yet. But here's how I would expect that to result in the log:

{
  req: {
    user: {
      email: 'email value'
    }
  }
}

Does that match your expectation? I'm open to suggestions.

[hasancansaral]

@rosston Ah, I see. And yes, that would be the behaviour I expect. However, I think that a feature would be useful that could enable one to change key names/nested structure. For example, that would be great if I could log the user email as:

{
  req: {
    user: {
      email: '<emailValue>'
    }
  }
}

or even:

{
  req: {
    user: '<emailValue>'
  }
}

That was my requirement for the case that one of my projects using basic http auth kept the user in the req as a simple key-value for the key user, while another project had the user as a nested json in the req, both of which were logging to the same Elasticsearch, so we wanted to keep the log format unified.

[rosston]

@hasancansaral (Sorry, late reply.) That is an interesting use-case you have there. I can understand the problem, but that seems like a fairly niche requirement to me.

As always, I could be wrong (and am happy to be!). If I am, please feel free to open a separate issue. I feel like the solutions for your use-case and original issue here would be very different.

[hasancansaral]

I agree that this is quite a different requirement, and should be considered in a different issue, or feature request, whatever that is 😋 And it also has a workaround, one can put the data into the req in whatever format they require, which will automatically handle the requirement.

[oleiba]

+1

[adamcohen]

So, with the current version, this process can be supported pretty easily with lodash:

requestFilter: function (originalObj, propName) {
            return _.get(originalObj, propName);
        }

@mbonig how exactly does the above allow you to define a blacklist with user.email and have it stripped out from the logs? It just seems like the above will allow you to fetch the propName from originalObj and no actual filtering is performed.

[mbonig]

@adamcohen That's a good question. I don't recall what I was thinking at the time.

[adamcohen]

@mbonig thanks for the response - I was sitting here scratching my head trying to think of what piece of the puzzle I was missing to make this filtering happen using only _.get(). At least now I know there's additional logic required to implement filtering.

[mbonig]

@adamcohen So, I think where my head was:

_.get() will take care of nested property names, so 'user.email' (https://lodash.com/docs/4.17.11#get) and allow you a very simple implementation on that requestFilter function.

... but hey, two years ago =-}

[mi-mazouz]

any update? this feature is a must to have!