Example Path: examples/Configuration/Web/BasicWebConfig

The system configuration web page interface is located on network port number 20034. This example demonstrates how to provide the same configuration interface as part of your application web server on port 80 (or 443 for SSL/TLS), so that you can customize it to be consistent with the rest of your application web pages.

The web page is dynamically generated, and provides access to view and/or modify boot and interface settings, such as default serial port baud rates and IP addresses, as well as application specific data.

The code used to generate and process the web form is in html/index.html. This example does not use any external JavaScript libraries, and all of the form generation code is located at the bottom of index.html. For a more advanced example that adds custom application configuration objects, please see the CustomWebConfig example.

Currently available config objects that can be used are as follows:

config_obj // base object, used as a container for other objects
config_bool // boolean
config_int // integer
config_double // double float
config_string // string
config_chooser // multiple choice option
config_pass // password
config_IPADDR4 // IP4 Address
config_IPADDR6 // IP6 Address
config_MACADR // MAC Address

Note that because we are only processing the config object, we are able to avoid writing a custom POST handler that is used in the other examples. If you include more to your web interface than is provided here, that will need to be incorporated as well.

Plain vs TLS: BasicWebConfig and BasicWebConfigWithTLS

This example serves the configuration page over plain HTTP. A companion example, BasicWebConfigWithTLS, adds SSL/TLS. They are kept as two examples on purpose; here is the trade-off so you can choose the right starting point.

A single application can actually serve both: BasicWebConfigWithTLS calls EnableSecureConfigServer(false), where false means "TLS or plain", so that build already accepts both HTTPS and HTTP. The split into two examples is about firmware footprint, certificate setup, and keeping each lesson focused - not a technical limitation.

Aspect	BasicWebConfig (this example)	BasicWebConfigWithTLS
Transport	Plain HTTP only	HTTPS, and plain too via EnableSecureConfigServer(false)
SSL/TLS library	Not linked	Linked - roughly doubles the firmware image
Certificate/key	None needed	Required - compiled-in cert/key (ServerCert.cpp/ServerKey.cpp) plus serial commands to load/validate them
Extra setup	None	Generate and provision a server certificate (see the CreateCerts scripts)
Best for	Closed/trusted networks; smallest build; learning the basics	Security-sensitive deployments; protecting config read/write in transit

Pros of staying plain (this example): smallest image, no SSL dependency, no certificate management. Cons: configuration data - including any passwords - travels in the clear, so it is only appropriate on a trusted network.

Start here to learn the config-mirror itself, then move to BasicWebConfigWithTLS when the traffic needs to be encrypted.