> It still beyond me how this kind of data structure actually works during authentication on every connection then, but you probably can ignore what I said earlier regarding hashes.
The journal is irrelevant at runtime during authentication. When the broker starts it reads the contents of the journal into memory. That's the whole purpose of the journal. The journal is never read again after that until the broker is restarted. As users are added, removed, modified, etc. the broker writes new records to the journal, but nothing is read from or written to the journal during authentication. The broker simply uses the data it has in memory. Justin On Thu, Apr 7, 2022 at 1:20 PM Vilius Šumskas <[email protected]> wrote: > >> Correct me if I'm wrong on my understandings. My proposal was to not > > store hashes (or plaintext passwords) in b) type records. > > > As far as I can tell, you believe that "surviving records" and > "operational records" are two fundamentally different things which is, in > fact, not the case. As I noted in a previous email, the "data print" > command simply lists the "surviving records" as a convenience for > readability. The only kinds of records which *actually exist* in the > journal are the "operational records." > > > To use an analogy, surviving records are to operational records as net > income is to gross income. > > I see. It still beyond me how this kind of data structure actually works > during authentication on every connection then, but you probably can ignore > what I said earlier regarding hashes. > > > If that happens you can run the "data compact" command to remove any > stale operational records that contain the plaintext password(s). > > I agree, however to actually *know* that you have to run "data compact" > one must know how journal works. But I guess that's another question for > another day. > > Thank you for detailed explanations! > > -- > Vilius >
