On 05/29/2014 09:31 PM, [email protected] wrote: > On 05/29/2014 06:13 PM, [email protected] wrote: >> Howard Chu wrote: >>> [email protected] wrote: >>>> It seems that modify requests which failed due to Invalid DN syntax (34) >>>> are >>>> not >>>> written to accesslog-DB. I guess that those requests get abandoned by the >>>> frontend and never reach the backend at all. >>> >>> Correct. >>> >>>> It would be handy to see the invalid modify request in the accesslog-DB >>>> though. >>>> >>>> Any chance to achieve this? >>> >>> Not likely. The frontend must call select_backend() based on the incoming DN >>> to determine which backend to invoke, and thus which stack of overlays are >>> involved. If the DN is invalid, no selection can occur. >> >> Hmm, I've done some more tests. Invalid syntax (21) also does not make it >> beyond the frontend into accesslog-DB. >> >> I have no clear opinion on this. Of course the current behaviour is good for >> performance. But sometimes one would like to observe what broken LDAP clients >> sent in a modify request in the past. >> >> Also running with BER loglevel or breaking up the TLS connection with stunnel >> and sniff with Wireshark is not always an option. >> >> Having this configurable would be great. >> >> What's your opinion on this? > > In terms of code architecture, overlays have been designed to work on > validated data (the request must be well formed). To this end, the > notion of "frontend" database was added to make it possible to layer an > overlay *before* backend selection. > > To have a custom piece of code muck with a request before it is > validated (or even before it is parsed) you need to split the code into: > > - parsing, without doing any sanity check > > - allow custom code to step in > > - do validation afterwards > > This does not necessarily imply performance penalty (when no custom code > steps in, the amount of operations would be the same for sane requests; > in case of malformed requests, you would miss the opportunity to bail > out on the first inconsistency). > > However, it would imply significant refactorization of the current code, > without (IMHO) a strong motivation for it: malformed requests are > already handled in terms of response to clients, and somehow logged. > > An (expensive) alternative would be to register a handler at connection > level which duplicates the parsing to anticipate checking for errors > that would be detected before passing control to the frontend. Not the > way I'd go, unless strictly necessary. > > A paranoid but intriguing alternative would be to implement an operation > mode that keeps parsing after the first error is detected, turning the > operation into a no-op. Again, lots of refactorization and error > handling and so on (for example, what if a syntax, an attribute > description or a matching rule is not found? You'd always have to check > that the corresponding pointer is not NULL before using it, whereas > right now we often assume that if execution got there, data must be > consistent. Of course, we could introduce dummy syntaxes > "NonExistingSyntax", ..., but we'd probably need to define their > semantics in such a way that they apply to every case we need to handle > and so).
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.) p. -- Pierangelo Masarati Associate Professor Dipartimento di Scienze e Tecnologie Aerospaziali Politecnico di Milano
