Sorry, I forgot to mention this is with the freshly released 2.3.7
> Le 12 juil. 2019 à 16:43, Aki Tuomi via dovecot <dovecot@dovecot.org> a écrit > : > > Would you like to try with 2.3.7? It was released today. > > Aki >> On 12/07/2019 17:05 Jean-Daniel Dupas via dovecot < dovecot@dovecot.org >> <mailto:dovecot@dovecot.org>> wrote: >> >> >> An other issue is that when 'request->passdb_success' is FALSE, the request >> fails but the error field is not set (as it is only set when >> request->failure is TRUE), which make it hard to create metrics for failed >> login attempts. >> >> We have (assuming success were working as expected): >> - success = yes -> means auth OK >> - error is present -> means request failed for some reasons >> - neither success nor error is present -> means requests failed for other >> reasons. >> >> As we can't create metric filter testing field absence, getting the count of >> failed requests would mean create 2 metrics (one for success, one for all) >> and diff the 2 to get the count of failed attempts. >> >> >>> Le 12 juil. 2019 à 15:31, Jean-Daniel Dupas via dovecot < >>> dovecot@dovecot.org <mailto:dovecot@dovecot.org>> a écrit : >>> >>> Hi, >>> >>> I'm playing with the new events, and encounter some issues: >>> >>> First the 'auth_request_finished' event is documented as having a >>> 'successful' field, but in the code, the field is defined as 'success' >>> (e->add_str("success", "yes")). >>> >>> But more important, in the function "auth_request_success_continue()" >>> (auth/auth-request.c:288), "auth_request_log_finished(request)" is call >>> (line 303) before updating the request status: "request->successful = TRUE" >>> (line 312) >>> >>> So the log function never set the success field to "yes" as at this point >>> request->successful is still false. >>> >>> Jean-Daniel >>> >>> >>> > > --- > Aki Tuomi
