xsoheilalizadeh / raccoonlog Goto Github PK

In some scenarios or someones may not need a CancellationToken
Instead of trying to pass CancellationToken.None necessarily, It is better to optional that argument with CancellationToken = default.

That's why all .NET async APIs has optional CancellationToken.

If you’re writing general-purpose library code, use ConfigureAwait(false).
For more information you can read Stephen Cleary's article, ConfigureAwait FAQ

If you think ConfigureAwait(false) is no longer necessary in .NET Core or ASP.NET Core.
It's wrong.

ASP.NET Core has not own SynchronizationContext. That means that code running in an ASP.NET Core app by default won’t see a custom SynchronizationContext, which lessens the need for ConfigureAwait(false) running in such an environment.

But it doesn’t mean, however, that there will never be a custom SynchronizationContext or TaskScheduler present. If some user code (or other library code your app is using) sets a custom context and calls your code, or invokes your code in a Task scheduled to a custom TaskScheduler, then even in ASP.NET Core your awaits may see a non-default context or scheduler that would lead you to want to use ConfigureAwait(false).

This feature gives us the ability to have a realtime log streaming in third-party service and a self-hosted client.

In this scenario, each storing progress will be queued and then dequeued by a background task. This feature brings more responsiveness for application and reduces the Network latency.

Support ElasticSearch for data store

According to Stephen Cleary's answer in Why would one use Task over ValueTask in C#?

As such, the default choice for any asynchronous method should be to return a Task or Task. Only if performance analysis proves it worthwhile should a ValueTask be used instead of Task.

In addition, the performance of ValueTask in most scenarios is fewer than Task. You can benchmark it with a few different scenarios.

The title is clear :D

Description

Ability to encrypt sensitive data in logs that user could enable/disable in configuration options.

Requirement

HTTP Logging Consideration

Headers

Credentials like Authorization, Proxy-Authorization header in request and custom header in response/request.

Cookies

Most of web applications use cookie for authenticate their user.

Query strings parameters

Query string isn't safe place for pass sensitive data but some people do it.

Body

HTTP Request/Response both have body and its data could be login form with password

Claims

User claims could have sensitive data too.

API Purpose

Configuration options

public class HttpLogSensitiveDataOptions
{
    public HttpRequestLogSensitiveDataOptions Request { get; } 

    public HttpResponseLogSensitiveDataOptions Response { get; } 

    public Dictionary<string, ProtectType> Claims { get; set; } 
}

public class HttpMessageLogSensitiveDataOptions
{
    public Dictionary<string, ProtectType> Headers { get; set; }

    public HttpMessageLogBodySensitiveDataOptions Body { get; } 
}

public class HttpRequestLogSensitiveDataOptions : HttpMessageLogSensitiveDataOptions
{
    public Dictionary<string, ProtectType> Parameters { get; set; } 

    public Dictionary<string, ProtectType> Cookies { get ; set ; }

    public Dictionary<string, ProtectType> Forms { get; set; } 
}

public class HttpResponseLogSensitiveDataOptions : HttpMessageLogSensitiveDataOptions { }

public class HttpMessageLogBodySensitiveDataOptions
{
    public Dictionary<string, ProtectType> JsonKeyValues { get; set; } 
}
public enum ProtectType
{
    Truncate,
    Encrypt
}

Data Protection

public interface IDataProtector
{
    string Protect(StringValues value, ProtectType protectType);
}

This feature gives us the ability to use multiple data stores at the same time.

This feature gives us the ability to debug and read binary format gRPC messages.

Support MongoDb for data store

If you want more performance you can use LoggerMessage pattern

High-performance logging with LoggerMessage in ASP.NET Core

LoggerMessage provides the following performance advantages over Logger extension methods:

• Logger extension methods require "boxing" (converting) value types, such as int, into object. The LoggerMessage pattern avoids boxing by using static Action fields and extension methods with strongly-typed parameters.
• Logger extension methods must parse the message template (named format string) every time a log message is written. LoggerMessage only requires parsing a template once when the message is defined.

Using IOptionsSnapshot<TOptions>, you or your library users can reload the configuration without relaunching the application.

In this feature, we're able to ignore the requests by configuring their path.