[Twisted-Python] Five Crazy Ideas to Start Your Week
glyph at twistedmatrix.com
Wed Oct 9 14:44:14 EDT 2002
On Tue, 8 Oct 2002 20:08:14 +0300, Tommi Virtanen <tv at twistedmatrix.com> wrote:
> On Tue, Oct 08, 2002 at 02:04:24AM -0500, Glyph Lefkowitz wrote:
> > These URLs need to be able to represent transport mechanism (TCP? UNIX socket?
> > SSL? Weird firewall-tunneling stuff?)
> "Talk to subprocess that runs this command to connect to the other end"
> ("ssh remotehost pbserver", "ssh remotehost
> connect-stdinout-to-unix-socket /path/socket")
> And yes, I may want that even after Twisted has a fully working
> SSH implementation. For rex :)
I don't quite get what you're talking about here. You want the URLs to be
shell command-lines? :)
> I think you may want to look at SASL for ideas on
> authentication. It seems to be the standard way to add generic
> authentication support to a protocol these days.
>From what I can tell, it wouldn't work at all for PB. From the RFC:
In the case that a profile explicitly permits multiple successful SASL
negotiations to occur, then in no case may multiple security layers be
simultaneously in effect. If a security layer is in effect and a subsequent
SASL negotiation selects no security layer, the original security layer
remains in effect. If a security layer is in effect and a subsequent SASL
negotiation selects a second security layer, then the second security layer
replaces the first.
I understand that there are considerations where authentication is bound up in
link-layer security (public key crypto) but for most cases I'd like to keep
them separate so you can authenticate to multiple objects requiring different
authentication conversations in the same session.
> > pb://pyramid/service#perspective
> What part talks about TCP/UNIX/etc? service? Then it needs more
> structure to it.
Same as with HTTP:
pb://pyramid/service == pb-tcp://pyramid/service
> > pb://pyramid/identity:password@service#perspective
> Eww. Passwords in URLs is baaad. Because users like to enter URLs on
> command line.
> I'd much rather see an explicit "--password-file filename" and
> "--password-fd n".
Yes, and smart users will use that, for the most part. Still, you need a way
to represent simple authentication as part of a URL. Sometimes the URLs
themselves will be secret and the authentication information will be a swiss
number or something. E does everything through exchange of URLs, and it's
> > Public-key authentication mechanism, using the same identity name. Connection
> > over SSH transport (sshkey auth only available this way).
> > pb-ssl://pyramid/cert$identity@service#perspective
> > PB over SSL, using certificate auth.
> > pb://pyramid/this/that/the-other/my-service#perspective
> Hmm. Idea. Allow one to specify when the server is trusted. "Connect
> to server X if its public key has fingerprint F." http://www.fs.net/
Any proposals for how to implement that?
> > [ ... ]
> > - <img /> or <object /> tags that automatically download other items, which
> > Again, don't allow these tags. Or, have the server-side site download the
> > images and verify that they are PNGs (alternately also doing PIL stuff to
> > remove steganographic information, if you're _really_ paranoid).
> Your basic problem here is that you are trying to disallow
> things you know are not safe. That assumes you are omnipotent.
I assume you mean "omniscient". If I were omnipotent, I would smite skript
kiddies with lightning from the sky, and forget about all this software-level
> While not contesting that, I still feel the only sane architecture is
> to catalogue known safe things, and only allow those. Something like a
> DTD/schema should do the job.
Okay, you have a point. Still, it is useful to know which are potentially
problematic so that we can allow the usage of things like IMG with appropriate
warnings and links that remove session privileges first.
> > Even if I managed to get this right for the web, though, trying to avoid lock
> > in to the web's way of thinking about forms is very tricky! I have yet to
> > seriously think about how GTK, PyUI, or Tkinter would work with this. I have
> > spent a little while thinking about how a text-based virtual world interface in
> > twisted reality, though, and that should be pretty easy (building a machine
> > with dials, knobs, etc, and a big button for "submit").
> IMHO, form-based GUIs suck horribly. A GUI is good only if
> it is interactive -- dynamic in some way. Most of the current
> GUIs only try to reach rich with forms that change
> Have you ever used mc-foo fan? While certainly not the greatest GUI in
> the world, imagine you had to use it through forms.
Some GUIs simply don't work with forms.
On the other hand, there's a large class of GUI that does. In fact some might
say that most of the GUIs in the world are form-based. If forms couldn't
represent a large number of things that people want to do when interacting with
a computer, then the web would have died an early death.
> > squatting. I think that by having a distributed naming system (where different
> > people call the "python" group different things, but python at twistedmatrix.com
> > will always get you to the one you're looking for) might circumvent squatting.
> So user A will see python at python.org as "python", user B will see
> python at twistedmatrix.com as "python", and if those two ever have to be
> squashed to the same namespace, user A will see "python
> (python at python.org)" and "python at twistedmatrix.com" and user B will see
> "python at python.org" and "python (python at twistedmatrix.com)"?
This is how e-mail naming works, isn't it? User A is connecting to python.org,
user B is connecting to twistedmatrix.com. The difference is that hosts may
provide either redirects for a certain name between each other, or relays for a
particular channel (a-la ry).
> This problem may be easier to think of in terms of nicks than of
> channels; IIRC there was some chat system that under the hood
> identified users with user at host (unix user id / email, whatever), but
> allowed them to set their list of "preferred nicknames". User A would
> see user B with the first available preferred nickname from B's list,
> or as userB at hostB if none was available. And this was, IIRC, done fully
> in A's client; if B and C saw different people (were on different
> channels), they could see A with a different nickname.
This is an interesting idea, but it has the potential to be pretty confusing, I
think. Tacking on an implicit domain name to channel/user names is a
convenience, but shifting around the displayed name is potentially even more
confusing. (At least: as I understand it, I was thinking the user would type
"join python" and get a window that says "python at twistedmatrix.com"; what
you're suggesting is that the user types "join python at twistedmatrix.com" and
gets a window that says "Arglebargle!" because that is the python group's
preferred nickname? )
Thanks for the response.
| <`'> | Glyph Lefkowitz: Traveling Sorcerer |
| < _/ > | Lead Developer, the Twisted project |
| < ___/ > | http://www.twistedmatrix.com |
More information about the Twisted-Python