First, let me admit: I don’t like auto login. So my my opinion on this might be biased… But still…
I think the possibility/ feature of logging in a user automatically doesn’t have to do a lot with the concept and encapsulation of a user’s identity. So any chance to separate those two things into two interfaces instead of combining them in one?
I know that auto login is a frequent requirement, so to come up to that, the default web app’s user implementation could still implement both interfaces, user application component could still be configured to allow auto login. But it shouldn’t be a must have.
Basically whenever you reuse an existing userbase that doesn’t yet implement the concept of authKeys, you’re left with a couple of choices:
-
set up additional storage to extend the existing user data -> a lot of extra work if I basically don’t intend to use that feature.
-
don’t implement authKey methods (empty dummy implementation/ throwing “not implemented” exception) -> Feels wrong. If it doesn’t implement the whole interface, then it simply isn’t an implementation of the interface. Can’t be properly reused.
-
use the password as authKey -> Bad idea, isn’t it?
-
use a hash function to generate authKey from existing persistent user data -> yep, this seems to work. But the again: if it can be done in such a generic way, then why implement it for each and every interface implementation? It could as well be one implementation of the "auto login interface", which could then be reused for all "user identity interface" implementations.