Ticket #712 (closed enhancement: invalid )

Opened 5 years ago

Last modified 1 year ago

cred for foolscap

Reported by: warner Assigned to: warner
Type: enhancement Priority: low
Milestone: Component: foolscap
Keywords: Cc: glyph, warner
Branch: Author:
Launchpad Bug:

Attachments

Change History

  2004-09-11 03:54:50+00:00 changed by 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

  2005-10-27 13:21:42+00:00 changed by glyph

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

  2005-10-27 23:19:14+00:00 changed by 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.

  2006-05-27 01:12:38+00:00 changed by glyph

  • owner changed from glyph to warner

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

  2007-01-17 00:06:30+00:00 changed by warner

  • priority changed from normal to low
  • component changed from pb to foolscap
  • summary changed from [newpb] cred for newpb to cred for foolscap

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.

  2007-01-17 04:33:58+00:00 changed by 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.

  2008-06-16 18:06:43+00:00 changed by exarkun

  • status changed from new to closed
  • resolution set to invalid
  • branch deleted
  • author deleted

  2008-06-16 19:10:43+00:00 changed by warner

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

Note: See TracTickets for help on using tickets.