[RFC] Add custom configuration parameter handling layer

[chintal]

This is a quick example of what I suggest in #381 and is put here for comment. At the very least, some minor cleanup will be needed before merge. In practice, I expect many other changes will be needed to make it safe.

The goal of this PR is to provide the "Additional Configuration" tab, which has only user defined fields.

The fields are defined in includes/config.php. A more appropriate location for these definitions may be found if editing includes/config.php is typically not user editable. The following are the new lines added to the config.php, for an example use case for providing proxy configuration options :

define('RASPI_CUSTOM_CONFIG', '/etc/raspap/custom.ini');
define('RASPI_CUSTOM_ENABLED', true);  // Default should be set to false

// Custom Configuration Parameters
define('RASPI_CUSTOM_FIELDS', array(
    'Network Proxy Configuration' => array(
        'host' => 'Network Proxy Host',
        'port' => 'Network Proxy Port', 
        'user' => 'Network Proxy User', 
        'pass' => 'Network Proxy Pass'),
));

Of these lines, RASPI_CUSTOM_FIELDS would be empty in the default case. The user would be able to add any number of configuration blocks to these fields as shown for one block above.

These configuration parameters are saved to the ini file specified by RASPI_CUSTOM_CONFIG, which must also be created by the user and given appropriate permissions (tested to work with chmod www-data:www-data).

$ cat /etc/raspap/custom.ini 
[NetworkProxyConfiguration]
host = test
port = adfkasjf;
user = 
pass = 

It will be left to the user of raspap to do with the custom.ini and its content what they want. In this example, for instance, proxy settings are not actually propagated anywhere by raspap. It will be upto the user application to read this configuration file, just as it was the user's decision to use this approach.

Assuming the general idea is acceptable, the following are left to be done or atleast considered :

1. The default configuration should be changed to disable this and RASPI_CUSTOM_FIELDS should probably be empty by default.
2. Status messages are currently not generated, and should be.
3. My logs are currently full of Undefined index: HTTP_X_CSRF_TOKEN from this page, and I'm not sure why.
4. Some means to specify validation per field may be considered. A starting point could be to add another layer of array, for ex. 'Network Proxy Host' would become array('desc' =>'Network Proxy Host', 'validator' => $some_func).
5. The only translatable string added here is "Additional Configuration". The rest of the strings are all user generated. A means to allow the user to add their own supplemental translation files might be useful. For a number of users like me not targeting multiple languages, though, the user generated strings themselves can be in their desired language.

[glaszig]

so this is basically only an ini-based key-value store for "arbitrary" values used for... arbitrary purposes. not sure if this fits the scope of the project. also, the menu item says "configure application" and the fields indicate proxy configuration. but that's not what it actually does. quite confusing, imo.

Undefined index: HTTP_X_CSRF_TOKEN

that's stupid php noticing access of a non-existing key in an array. can be ignored.

[chintal]

The language can be worked on.

Proxy is what I want to use it for, but it isn't strictly restricted to it. Proper proxy support needs a great deal of fiddling around which isn't quite worth it, in my experience. You'd have to set it in a number of places across the system in the most general case, and those locations are system specific. This way, its upto whoever decides to use this approach to figure out what to do with the configuration parameters within their RPi.

This would allow me to provide a way to inject some configuration values as an ini-based key store which is accessible via raspap. For some ancillary configuration in situations where direct user input is not possible, I won't need to replicate a lot of what raspap already does. At present, for proxy configuration, which I do actually need to add, I have no good way to inject it into an RPi without physically connecting to it. The 'best' way is to use RaspAP to generate an hotspot, and then ssh into the system, configure the proxy, then use RaspAP to switch to the regular wifi AP. That approach leaves something to be desired, and cannot reasonably be deployed.

[chintal]

Renamed to "Additional Configuration"

[billz]

How is this fundamentally different from the existing TorProxy and OpenVPN custom config stubs?

[chintal]

@blitz I haven't seen those very closely. That said, this is mainly different in the way it shows up to the user (by user I mean the person setting up raspap).

This is intended to be advertized or documented to be free-form from the get go, and available for the user to add whatever configuration parameters they want to this. You would not ship this as proxy configuration - that's just an example shown here. It'd actually ship hidden and with a blank configuration items array.

This is more along the lines of #156 and #167. As per your comment there, if you'd rather not include this in raspap, that's fine. I've been able to use my 'fork' of raspap to provide the basic functionality I need to my application.

I do believe that this is a missing piece in the RPi ecosystem, though, and raspap already does 95% of the work to solve the problem. If you look at raspap as a tool which allows you to configure networking on a pristine copy of a distributable image installed to a headless RPi, then this gives the user the added capability to define additional configuration options which that specific application needs to expose to the end user. And more specifically, to be able to do in a sanctioned, documented way as opposed to having to overcome the barrier at looking through the sources and changing them, and the continuing effort that will be needed to handle merges with upstream over time once you're committed to maintaining a personal fork.