lwhiteley / AngularLogExtender

AngularLogExtender is an AngularJS module that extends the Angular $log functionality. It uses the native $decorator to push the $log pass its capabilities and provide new functionality such as configuring the $log for different environments such as production and development
MIT License
40 stars 8 forks source link

Custom output filtering #16

Closed endorama closed 10 years ago

endorama commented 10 years ago

Hello, thanks for this library! I've started using it and is really useful.

I've a question for you: in my application I need to filter out some "private" datas from the logged data ( like password and other sensitive informations ). I was thinking if there is the possibility to custom filter the output from the log, so that I can use a custom defined filtering function to hide those data.

Is that already possible? If not, can you give me an hint on how to add this feature? ( I'm not so used to the splitting in the files I've seen in the repo :) )

Thanks for your effort, cheers

lwhiteley commented 10 years ago

hey, Not very certain how exactly you are logging out this information. An example would be nice :+1:

currently there is no explicit filtering functionality in the library.

However, using our template engine you will see that it matches templates to property names in an object.

Refer to readme - use case 5

Passing an object to a template string only prints out selected properties.

eg.

app.controller('CoreController', ['$scope','$log', function($scope, $log) {
      $log = $log.getInstance('CoreController', true, true);
      $log.log('Advanced Log Extender Example: Use Case {example}', {example: 6, password: 'this-is-a-password'});
//  result => 'Advanced Log Extender Example: Use Case 6'
}]);

Only the property example was replaced in the string.

Any other method used to log out this object will print out all properties of the object, unless you explicitly remove the property before logging it out.

Another recommendation would be to not have sensitive data like passwords in the front-end of your app. Smart people can still find ways to see them without checking logs.

Let me know if this was helpful.

lwhiteley commented 10 years ago

Also sorry for not mentioning but if this wasn't helpful then providing me with an example will give me a better idea of how and where these things can be filtered out in the code :+1:

ferronrsmith commented 10 years ago

I think what he means is, he wants the equivalent of the rails filter_parameter_logging.

class ApplicationController < ActionController::Base
  # filter out password parameters from log files
  filter_parameter_logging :password  
end

So for example if there is an object to be logged:

app.controller('CoreController', ['$scope','$log', function($scope, $log) {
      $log = $log.getInstance('CoreController', true, true);
      $log.log('Advanced Log Extender Example: Use Case {example}', {username:'joebrown', fname:'joe', lname:'brown', password:'23akslasklas'});

}]);

What's printed in the console should either be :+1:

// ignore the password field
{username:'joebrown', fname:'joe', lname:'brown'}

// filter the password field
{username:'joebrown', fname:'joe', lname:'brown', password:'[FILTERED]'}

And for string interception

app.controller('CoreController', ['$scope','$log', function($scope, $log) {
      $log = $log.getInstance('CoreController', true, true);
      $log.log('Advanced Log Extender Example: Use Case {example}', "password:'23akslasklas'"});

}]);

A pattern could be searched for using the filtered_params specified

/(filtered_param_1|filtered_param_2|...):?\w*/.test(_log_message_).

//output
"password:''[FILTERED]"

This will require a new provider override that accepts the list of fields/string to ignore

app.config(['logExProvider', function(logExProvider) {
    logExProvider.filter_parameter_logging(['password', 'credit_card_number']);
}]);

Should be something simple to implement. It just depends on how powerful you want to make it.

lwhiteley commented 10 years ago

hmm interesting...

I think ignoring the filtered field would be ideal. What do you think @endorama ?

either way. I think you just assigned yourself @ferronrsmith :)

ferronrsmith commented 10 years ago

Working on #19, so you can take this one.

lwhiteley commented 10 years ago

k will look at it then after confirmations.

endorama commented 10 years ago

Hi guys sorry for the late reply but here is saturday and I wasn't able to get to the pc until now! :)

@ferronrsmith got me right, and my idea was exactly that.

To better clarify my purpose: I'm working on a fair complex angular application, that is currently in beta ( and we have many beta testers ). The $log debug output is enabled and is attached to issues, so that we can have a look at it when checking bug reports to better understand what was the problem encountered by the user. All communications with the backend is handled by websockets, and our application requires login and handles connection to wifi networks, plus some information is encrypted with custom keys. Obviously this sensitive data appears in logs, and this is not something we want. Before discovering this module we used a really simple logging class, whit a recursive function to hide the content of all the sensitive fields ( so 'password,encryption-key` and some others ) at the logger level. In this way there is a little to zero possibility for a developer to print sensitive data ( because if you use the logger class everything is handled for you; opposed to the template engine solution which is up to the developer to use correctly ).

The solution proposed by @ferronrsmith is exactly what we need, and if would be possible to replicate the Rails behavior that would be awesome. I would prefer to hide only the content of the filtered fields, so that is clear that a field is present but the content is sensitive and should not be displayed.

If I can help you with this just ask me :)

Thanks

lwhiteley commented 10 years ago

Kool i understand.

Ill create a branch for this tonight and get the implementation going.

I added you as a collaborator @endorama. So you can get involved where needed.

Will get back to you later.

lwhiteley commented 10 years ago

now closed. this feature can now be accessed with the latest version via bower @endorama

endorama commented 10 years ago

Thanks! :)