[Twisted-Python] Re: cred and stateless protocols

Manlio Perillo manlio_perillo at libero.it
Mon May 8 14:25:07 MDT 2006


Phil Mayers ha scritto:
>> Since I think that the procedure is similar to HTTP session handling, I
>> was asking if there is some reusable support for creating "secure"
>> session id and if cred has some support for this.
> 
> Ok. You're wrong that they're similar, but let me give the short answer
> to the latter question:
> 
> No, cred does not provide secure session IDs. Cred is for authenticating
> credentials.
> 

Ok, thanks for the clarification.

> [...]

> HTTP does not have spectacularly good authentication support. The
> available mechanisms insecure in one way or another:
>  * basic - Credential exposure. No integrity. No privacy
>  * digest - No credential exposure. Minimal integrity (request body only
> - request headers, reply body+headers unprotected). No privacy.
> 
> ...or not standardised e.g. GSS over HTTP.
> 
> The only sensible solution to HTTP authentication for important
> applications is to use an HTTPS link, signed server certs and ideally
> client certs as well, 


Yes, but how many people knows how to set up a private certificate?
And how many sites uses certs verification?

It would be nice to store a certificate on a smart card and authenticate
to a web server using only that certificate.


> [...]

> Note: there are circumstances where other concerns outweigh purist
> security. For example, the Google gdata API uses an initial HTTPS GET to
> return an auth token, which is then supplied to the server over HTTP in
> an "Authorization: GoogleAuth THETOKEN" header. 

And this header should be supplied for every successive requests (like
cookies)?

> This provides much
> greater scalability and is similar to MS Passport (which itself is
> similar to Kerberos).
> 
> Presumably the token expires. You should note however that the token is
> NOT used for sessioning. HTTP 302 redirects and URL parameters are used
> for that. 


I'm not sure to understand this.

> You might ponder that Google separated out auth and sessions
> even in their engineering compromise.
> 
> Note that the above refers to the non-browser API. Presumably the
> browser API will use a passport-alike 302+cookie.
> 
> For open source examples, see PubCookie.
> 

Thanks for the link.
I have not read the source, but the "granting cookie" what type of
informations contains to be sure that the UA is the "right" one?

>>
>> By the way:
>> for user tracking in UDP, why not just use the peer address?
> 
> Pardon? Are you serious?
> 

Well, let me explain this better.
Unfortunately there are not examples of UDP servers in twisted.

Since UDP is connection-less, the first thing that come to my mind is:

class MyProtocol(DatagramProtocol):
    def __init__(self):
       self.users = {}

    def datagramReceived(self, data, (host, port)):
        context = self.users.setdefault(host, Context())
        response = context.handle(data)
        self.transport.write(data, (host, port))


Where the Context class keep an internal state, like IMAP.



Thanks and regards  Manlio Perillo





More information about the Twisted-Python mailing list