ua-parser-js VS FluentValidation

Just look at all the big companies doing it

https://faisalman.github.io/ua-parser-js/

This project is backed under MIT License, special shout out to project UA-Parser, as liguard uses a piece of its source-code.

With NPM, what's actually published is not what's in the git repo, so it's harder to inspect/review vulnerabilities or hijacking. With composer, what's in git _is_ what composer pulls (with the exception of rules in .gitattributes to exclude files etc), making it much easier to trace. One such example: https://github.com/faisalman/ua-parser-js/issues/536

Composer packages are vendor namespaced, so hijacking an abandoned package is not possible (and it is with NPM), some examples like https://www.theregister.com/2021/08/10/github_npm_package/

Sure, I suppose in theory it could happen with other ecosystems, but for some reason it doesn't. It sure seems to just keep happening in NPM though.

From the other side, npm package may be hijacked(as it happened recently for ua-parser-js and to other packages earlier). To mitigate that, I don't know, probably, subscribing to some security digest would be the most helpful.

On Oct. 22, 2021, developers of a very common NPM package, ua-parser-js, discovered that some attackers uploaded a compromised version of the package containing malware for Linux and Windows, and were capable of stealing data (at least passwords and cookies from the browser).

Since Neovim 0.5 release (which has full Lua support) I see more and more amazing Lua plugins being developed, and I think this trend will likely to continue. But I recently got more concerned about security risks associated with the way Neovim plugins being installed and used (especially after seeing recent compromises like ua-parser-js or coa). Installing typical Neovim plugin is basically downloading and executing random code from the internet on your machine with your user privileges, so hijacked or deliberately malicious plugin could potentially do a lot of damage (like stealing keys/passwords, installing keylogger or just rm -rf / for fun).

thread about compromise https://github.com/faisalman/ua-parser-js/issues/536

Here is an example of Command handler with built-in Fluent Validation and fire and forget style:

There is an RFC called Problem Details (RFC7807) that standardizes how an error in an API should be responded to for the client. If you use Fluent validation, you may have noticed that the response is within this pattern.

here we're defining the input validation requirements using fluent validation rules. let's see what happens when the user input doesn't meet the above criteria. execute the same request in swagger with the following incorrect json content:

I remember FluentValidation being a nice library for this type of stuff.

Literally the code example in the front page: https://fluentvalidation.net/

https://www.nuget.org/packages/Newtonsoft.Json/ https://www.nuget.org/packages/AutoMapper/ https://www.nuget.org/packages/Dapper/ https://www.nuget.org/packages/FluentValidation/ https://www.nuget.org/packages/FluentAssertions/ https://www.nuget.org/packages/NUnit/ https://www.nuget.org/packages/xunit/ https://www.nuget.org/packages/YamlDotNet/ https://www.nuget.org/packages/Moq/ That is simply not true. Mature c# projects purposely maintain no downstream dependencies and is they do, it's to a major reputable lib. See for yourself - these are staple third party packages commonly used. Anything dependency starting with System or NETStandard is Microsoft maintained.

FluentValidator for validating and authorising certain fields.

Now that we know the importance of providing users with enough information about their requests and how it was processed, let’s focus on how we can configure our API to help us do that.One aspect of such meaningful experience is Request Validation (400 Error Range). For that purpose I am using a library called Fluent Validation.