Request tracking with custom body serialization for reducing personal information
Request tracking was already available in a previous version of Arcus Web API. The tracking functionality allowed several options, plus several routing filters, on when/where the request tracking should take place. This request tracking functionality was also capable of sanitizing a custom set of headers that needed to be tracked. The reason behind this customization is that some headers should never be tracked: for example, authentication headers
While this is a very helpful feature, the customization was missing something crucial: we don’t allow custom sanitization of the request/response body. This too can contain sensitive or personal information that should not be exposed in any logging system. Arcus Web API v1.5 solves this in the same way the sanitization of headers occurs: with overridable functionality.
Here is a rudimentary(!) example of what this could look like. Note that all overridable functionality is optional and doesn’t have to be overridden.
This custom-made request tracking middleware can then be given to the registration of the request tracking. This means that the next time a request is processed, the personal and/or sensitive information is filtered out from the tracking.
Built-in JSON formatting extensions
Our Arcus Web API project template uses several highly recommended approaches to start off your project. One of these approaches is to limit the input/output formatting of models to JSON formatting only. What this means is that the registered input/output formats were inspected and altered. While this is a valuable addition to the Web API project template, the boilerplate code alongside the inspection code doesn’t make the template a very user-friendly or clean place to work in.
Arcus Web API v1.5 changes this. In a new library called Arcus.WebApi.Hosting, we have added extensions to the MVC options so that the JSON formatting limitation can be included in a more fluent manner.
These extensions will greatly help make the Arcus Web API project not only easier to understand, but more maintainable too. If we choose to change internal workings or additional built-in JSON features, we can update our extensions instead of altering the actual internal code of the project template. This means a cleaner approach for both consumers and maintainers.
Better JWT Bearer authentication extension with secret store access
Arcus is not only used to provide ‘new’ functionality. Most of the time, things are already there but need some finetuning, or have a ‘gap’ with other functionalities. Arcus provides a bridge, a way of connecting all the necessary functionality so that developers can focus on the actual implementation.
This new feature is a great example of this principle. JWT Bearer authentication is already available when configuring the authentication in your API. The problem arises when you want to register the issuer’s symmetric key. Due to the location of the JWT Bearer authentication registration, one doesn’t have access to the necessary registered services to retrieve some kind of private key. The general application configuration (see Configuration in ASP.NET Core) is the sole access point to retrieve such values. In a previous post, we stated that application configuration should only be used as configuration data, and not secrets. The Arcus secret store is the answer to this, but has not been available — until now.
Arcus Web API v1.5 provides consumers with an alternative extension to register JWT Bearer authentication, with access to the IServiceProvider. This supplies them with all the registered services in the application, including the Arcus secret store.
.NET 6 support
Last but definitely not least, is the long-awaited update for .NET 6 support. Arcus Web API is a widely-used library and was lingering behind due to the almost-deprecated .NET Core target framework. This update ends this struggle, while still supporting .NET Core for whoever needs it. This change is a part of a long process in which Arcus is being made fully .NET 6 compatible in its entirety. This is not the final step on the entire Arcus front, but is the last step on the Web API front.
Conclusion
Arcus Web API v1.5 has tons of new features and changes. Moreover, there’s a lot more to be found, such as a better developer experience with faulted HTTP correlation registration and non-escaped JSON serialization during request tracking.
See our official documentation for more information on all the currently supported features. If you have any questions, remarks, comments, or just want to discuss something with us, feel free to contact the Arcus team at Codit.
Thanks for reading!
-Arcus team
Subscribe to our RSS feed