divmod-users team mailing list archive

[exarkun@xxxxxxxxxxxxxxxxx]

On 12:09 pm, _@xxxxxx wrote:
> 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:

It seems like you must have seen axiom.userbase already.  It integrates 
Axiom with cred.  What are the problems with the approach it takes?

Even if you can't use it directly (perhaps because of something to do 
with substores?) it should demonstrate an approach you can mimic.
> - 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.

Adaption by calling interface objects is one approach.  Another approach 
is to just construct your adapters.

There is no `IPortal` because `Portal` is the only implementation anyone 
needs.

You can do something like:

   Portal(IRealm(store), list(store.powerupsFor(ICredentialsChecker)))

and now you have a portal that does what you want.
> 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.

I guess this sounds a little bit like what I wrote above, but I'm not 
sure why the implementation is ten times shorter than your description.
> 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?

No one is going to stop you, but it doesn't seem like a good (or 
necessary or even terribly useful) idea to me.

Jean-Paul