On 05/30/2014 01:33 AM, [email protected] wrote: > [email protected] 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 >> overlays) >> >> - 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. p. -- Pierangelo Masarati Associate Professor Dipartimento di Scienze e Tecnologie Aerospaziali Politecnico di Milano
