cred for foolscap

[warner]

glyph said he would look into cred for newpb. The basic PBClientFactory
.getObjectNamed/.getRootObject functionality is there, ready for .login to be
built on top of it.
pb.getRemoteURL/.callRemoteURL are related, and need work too

[glyph]

Apparently I lied.  Um.  Cleaning out my queue.  Did you do this sometime in the
last 13 months?

[warner]

Nope, it still needs to be done. Tag!
I lied too: .getObjectNamed/.getRootObject/.getRemoteURL/.callRemoteURL are
gone. The new approach is all about tubs (i.e. PBService) and URLs. One side
creates a tub and does .registerReference(target, name=OPTIONAL), which returns
a URL. The other side creates a tub and does .getReference(URL), which
eventually provides a RemoteReference.
I think cred should be layered on top, (and in a separate module, probably
twisted.pb.cred), so you create a PBRealm and give it checkers and stuff, then
do .registerReference(pbrealm, name="login"). The client end can have a function
that accepts a tub, a target URL, and your credentials.
I'm undecided about whether it is a good idea to expand upon the cred practice
of using Interfaces to distinguish "what" you want to connect to. If we do it,
we should probably use RemoteInterfaces instead, since every RemoteReference
that PB can return will implement the same (normal) Interfaces.
I'd like to see an example of how this stuff should be used first. The one thing
to remember is that we have secure references now, so we can support both
identity-based (i.e. cred) and capability-based (i.e. URL) access models.

[glyph]

I have no idea what to do about this at this point; does newpb have auth and such?

[warner]

no, there's no cred in foolscap. It might be useful (for cred-aware programmers or apps) to build a cred-like layer on top of the basic capabilities that foolscap provides.

Everything I've written with foolscap so far has been more capabilities-based: each client gets to know a different secret URL that gives them access to their account, and this URL is what they store rather than a username/password.

[exarkun]

A secret URL is just a different authentication mechanism. Cred isn't primarily concerned with username/password authentication. Authentication is part of it, but authorization is present just as much: deciding what someone can do after they have authenticated is also a big part.

[exarkun]

Foolscap issue tracker

[warner]

http://foolscap.lothar.com/trac/ticket/69 is the new Foolscap ticket for this.