mgkuhn
commented
7 years ago Hold the POST data in a separate cache-server process, preferably some existing tool with adjustable expiry policies (such as memcached). Advantages:
- can be shared by a cluster of load-balancing Apache servers,
- keeps each Apache server state free, i.e. can be rebooted any time.
It might also be useful to have an option to protect the cached POST data with an authenticated-encryption (AEAD) scheme, using the MAC as the retrieval key, which is then passed on to the WLS in params.
If an HTTP POST triggers authentication (whether or not this results in a authentication challenge) then the redirect via the authentication server causes the POST to be retried as a GET. This could confuse an application that distinguishes between the two, but more importantly results in the loss of any posted content. If this was, for example, a carefully-composed blog post then the loss is likely to be annoying.
Currently the module just writes a log record when this happens to make it easier to diagnose resulting events.
In principle it might be possible to store the POSTed content locally before triggering the redirect to the authentication server and then pick it up again following successful authentication and simulate the submission of the original POST. Care would be needed to securely and reliably match the stored POST data with the corect authentication response.
Simple approaches, such as storing POST data either in the URLs query string or in the params field of the authentication request aren't generally practical given that POST data can be large (file upload, for example).