Hi Laslo, > > Also think > > about providing a better abstraction, e.g. a possibility for the > > backends to have a void 'state' pointer that they can set up during > > initialisation. In this way, the passwd backend could store the entered > > password in this state (which might as well also be a full custom > > struct), and you save yourself from abstracting the input of characters > > through the auth-API. > > > > Going even further, maybe the best approach would be to have a > > well-defined event interface. Anyway, just keep it as simple as > > possible! > > This is a point I will gladly revisit. I'll get back to you on this.
I spent the weekend considering how to improve the abstraction. Better in my mind means more generic while keeping it reasonably simple. But everything I come up with adds both run-time as well as code complexity. As it stands, I am abstracting backend state using pointers to opaque structs that the backend can initialize and use as it needs (state->auth and state->wio->auth). This is like your idea of a void pointer, but without the need for casts. As far as what procedure should store the password, I believe that a general input function in the main slock module is best. The reasons are (1) it can be reused by any backend desiring keyboard input, (2) it can direct screen state in a uniform way, independently of the backend in use, (3) it keeps the backend slim, just sticking to its core functionality of authentication methods and authentication-related feedback, and (4) that way the handling of sensitive input data can be analyzed and verified in one place. Or did I miss where you were going? Kind regards, Sebastian
