-
Notifications
You must be signed in to change notification settings - Fork 123
Middlewares
WSGI is the "Web Server Gateway Interface", a simple and universal interface between web servers and web applications or frameworks. The WSGI interface intends to separate the choice of framework from the choice of web server, freeing users to choose a pairing that suits them, while freeing framework and server developers to focus on their preferred area of specialization.
The WSGI interface has two sides: the "server" or "gateway" side, and the "application" or "framework" side. The server side invokes a callable object that is provided by the application side. In addition to "pure" servers/gateways and applications/frameworks, it is also possible to create "middleware" components that implement both sides of this specification. Such components act as an application to their containing server, and as a server to a contained application, and can be used to provide extended APIs, content transformation, navigation, and other useful functions. Such "middleware" components can perform such functions as:
- Routing a request to different application objects based on the target URL, after rewriting the environ accordingly.
- Allowing multiple applications or frameworks to run side-by-side in the same process
- Load balancing and remote processing, by forwarding requests and responses over a network
- Perform content postprocessing, such as applying XSL stylesheets
The presence of middleware in general is transparent to both the "server/gateway" and the "application/framework" sides of the interface, and should require no special support. A user who desires to incorporate middleware into an application simply provides the middleware component to the server, as if it were an application, and configures the middleware component to invoke the application, as if the middleware component were a server. Of course, the "application" that the middleware wraps may in fact be another middleware component wrapping another application, and so on, creating what is referred to as a "middleware stack".
You can read about the WSGI in PEP-3333 where it is formally defined.
(TODO: add middleware "ring" diagram)
SATOSA is a web application that follows the application side of the WSGI interface; it is a WSGI application. In addition, it already defines and uses middleware to convert response content from an encoded format (ie, "UTF-8") to bytes, and since recently it features support for another middleware that duplicates specified cookies and handles the SameSite cookie attribute in order to solve the breakage that was by each browser vendor handling the SameSite cookie attribute differently, when the SameSite cookie attribute was introduced.
Middleware seem to be very useful in terms of decoupling network-facing components. Providing services through middleware makes them from the application or framework perspective more like libraries, and the application or framework itself less monolithic. At the same time it allows users to choose which middleware-service they need, thus giving them the choice to enable, disable or even swap middleware.
The plan is to make middleware a first-class concept in SATOSA. The SATOSA configuration will change to provide a middlewares configuration option that will list the middleware that should run. Each item in the list will be a string that represents the dotted python path to the name of the executable object that should be loaded. All middleware should feature the same initialization interface; that interface should be
(TODO: add example configuration for middlewares)
from typing import Any
from typing import Callable
from typing import Mapping
def __init__(self, app: Callable, config: Mapping[str, Any]):
...that is, the app that will be called next, and SATOSA's configuration through which the middleware is responsible to look at the bits it needs and extract the needed information to be operational.
Users should then have the ability to enable, disable or swap out middleware as they like.
(TODO: write how each item can be built with a middleware)
- extraction of trace-id from headers
- generation of request-id
- creation of logger instance that can bind/carry values
- customization of error handling
- handling of SAML unsolicited responses (to be investigated)