diff --git a/source/development/guidelines/basics.rst b/source/development/guidelines/basics.rst index 66dcdaa4..ed26c187 100644 --- a/source/development/guidelines/basics.rst +++ b/source/development/guidelines/basics.rst @@ -27,6 +27,39 @@ Architecture Documentation is available about our :doc:`architecture ` and used :doc:`components `. +----------------------- +Safeguard user input +----------------------- + +We aim to validate user input before injecting it in the configuration in order to provide a more user friendly +interface and prevent bad things to happen in the future. + +Although we do understand that the perfect validation isn't always possible at once (too much referential constraints, not always as easy to catch) +it is a best practice to ask yourself if a specific input could be validated (if not now, what about the future). + +The issue with user input impossible to validate is that it will bite you eventually, leading to future security issues waiting to happen +(for example a non authorized user can write commands that will be executed with elevated privileges, we saw this with openvpn for example). + +For this reason we do not allow plain text configuration data to be stored in our configuration +(although some legacy components still use this `opnsense/core#d62015 `__ ) + +.. Note:: + + Feature requests for custom user inputs will be declined in our public repositories, defining what a feature should do + also helps designing the right feature. + + +.. Tip:: + + If custom input is needed, in most cases you can use hooks to include additional configuration data in the service, + most services offer this type of support (either with predefined directories or via the template system). + + This prevents arbitrary users from adding undefined configuration data. + + +The different field types in our model system are aimed to help the developer safeguard his or her code for unexpected input. + + ----------------- Ideal Development -----------------