divmod-users team mailing list archive

[Laurens Van Houtven <_@xxxxxx>]

Hey,


I'm writing a library where you have a root store and a number of user
(sub)stores, and you interact with them over AMP.

I'd like to have pluggable authentication methods, for example,
password-based auth. These require, at least:

- one IBoxResponder (and preferably two: one for users that aren't logged
in yet and one for users that are)
- one ICredentialsChecker for actually checking these credentials

It seems that to use Cred properly, there should be:

- one Realm implementation that produces authenticated users' avatars (in
my case, IBoxReceivers)
- all of the above ICredentialsCheckers
- one Portal, to mediate between all of these

It seems that the most reasonable thing to do here would be to adapt the
root store to a Portal, but there's no IPortal interface. I could, of
course, just define that interface myself.

Alternatively, I could create an IService that, when started, collects all
of the authentication methods (so, there'd be an IAuthenticationMethod
interface), builds a portal, and creates all the IBoxReceivers. The issue
there is that the IBoxReceivers need to be available to the service that
actually allows AMP connections. That can be solved by powerup priorities.
Furthermore, since I can only install a single in-memory powerup for the
IBoxReceiver, I'd have to either persist them, use powerup indirection. All
in all, it sounds hairier than the previous idea.

So, I suppose the short way to ask this question is: is it okay to define
interfaces that upstream doesn't define just so you have something to
adapt/powerup to?

-- 
cheers
lvh