Webdar

The following describes the overall architecture of the webdar software

The webdar main() launches:

• a central_report object that will gather logs from all internal components and output them to a specified destination (command-line, syslog, or other alternatives)
• an authentication object to validate user provided credentials
• a ssl_context information that carries the necessary information to setup a server side SSL session
• a listener object for each IPv4 and IPv6 specified on command-line, they all receive the a pointer to the central_report and authentication module as well as a copy of the the ssl_context and the IP and port to listen on. Then the main() routine is pending for all listeners to end, or a signal to come to end the webdar process.

The role of a listener object is to create a proto_connexion for each new incoming TCP session. This proto_connexion is passed with pointers to the central_report and authentication objects to a new server object. Each server object with the help of a parser object transforms the TCP byte stream into a suite of HTTP request, and transmit back the corresponding HTTP answer. These answers are obtained from either:

• a static_object for static components (images, licensing text, and so on)!
• a challenge object if the client has not yet been authenticated
• a choose object if the client is authenticated but the pointed to session does not exist
• the user_interface object from the session pointed to by the HTTP request. The user_interface object is acquired by the server object from the session class.

the session class manages a list of session objects associated with a reference counter that keep trace of the servers that have been given the session reference (only one can interact with the session at a given time). Only when the counter drops to zero that a closing session request can be executed leading the session to be torn down. A few flags are also associated with this session object in that table (locked, running libdar, or closing).

The session objects manage a user_interface object to provide the answer to each HTTP request. this is associated with a semaphore for locking and the thread_id of the server object (which is from a libdar::thread inherited class) managing the session. Such server object has obtained the session management calling session::acquire_session() and has not yet called session::release_session().

user_interface class provides mean to setup HTTP response to HTTP request for that particular session. In other words, it handle user interaction thought the web interface. For that it relies on a set of body_builder inherited classes within which, complex objects are build from simpler ones. Body builder objects are setup under a tree-like hierachy of adopted body_builder objects, with the a html_page at the root. The user_interface class has several status and for each a different body_builder object is used to provide the body of the HTTP answer:

• config: object parametrage of class saisie
• listing_open: object in_list of class html_listing_page
• listing: object in_action of class html_libdar_running_page
• running: object in_action of class html_libdar_running_page
• error: onject in_error of class html_error

most if not all body_builder inherited class have a name starting with the html_* prefix Some components to behave as expected should be adopted by an html_form object, these classes have a name staring with html_form_*.

Pay attention that some objects are based on html_form (they contain a set of html_form_ components adopted by an html_form root object and have a class name starting with html_*_form_* like html_mask_form_path or html_mask_form_filename. These are not to be adopted by an html form as they embedd an html_form object as private field.