On 05/30/2014 01:33 AM, hyc(a)symas.com wrote:
> It now comes to my mind that another perhaps less intrusive chance of
> intervention could be to act at the *response* level. Think of:
> - the possibility to stack code in the response chain (not necessarily
> - have a way to understand if the response originates *before* the
> frontend was called
> In this case, the custom code could re-parse the request to re-detect
> why it failed and handle it (e.g. log custom information on failure
> reason). Not a piece of cake, but probably less intrusive than other
> options. (I'm not sure the raw request buffer is still available at
> this stage, though.)
Still not something useful for slapo-accesslog - we're storing log info as
LDAP attributes. We can't store reqDN if the DN has invalid syntax. We can't
store reqMod values if the attributetype is unknown or the values are invalid.
When a request fails validation it's literally garbage, and toxic - cannot be
considered safe to preserve in a DB.
Sure. Indeed, it could not be associated with accesslog (invalid DN
needs to be detected way before a database can be selected). Such a
case would belong to some "debugging" layer (e.g. client-server
interaction troubleshooting), which BTW I'm convinced the current
logging is more than enough for.
Dipartimento di Scienze e Tecnologie Aerospaziali
Politecnico di Milano