[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