[Twisted-web] [Nevow] new chapter about authentication
manlio_perillo at libero.it
Thu Aug 3 05:17:03 CDT 2006
Valentino Volonghi aka Dialtone ha scritto:
> On Tue, 01 Aug 2006 21:09:55 +0200, Manlio Perillo
> <manlio_perillo at libero.it> wrote:
>> I have written a new chapter for authentication.
>> It is still a draft (as always), and don't forget that I'm not an expert.
First of all, thanks for your review.
> Line 13:
> stateful is totally wrong and the opposite. Should be stateless.
Yes, a mistake.
> Line 15:
> Authenticate user means not only to assure that a user is who claims
> he is, but also to assure that a hostile user can gain unauthorized
> I think this is wrong.
> Authentication is just recognizing who is the
> user. Authorization is a different aspect that should be dealt with at a
> different level, although using the avatar concept it can be done in one
> step at cred level.
I'm interested in this.
Are there any examples?
I would like to add a section on authorization, too.
> Line 19:
> The most secure way is to use HTTPS, based on SSL. But SSL can cause
> too burden on an application.
> The most secure way to do what?
To use sessions.
> Line 25:
> The standard way to do authentication is via HTTP Basic
> Authentication, witch is supported in Twisted Web.
> Since this is a Nevow tutorial this should mention that it is supported
> by Nevow.guard.
Yes, you are right.
> The simple example is good although with guard it's even
> less than that.
Ok, but I think it is better a bottom up approach.
This allow one to understand (and appreciate) better what Nevow offers.
> Line 82:
> * when an user want to change the email and you send the forgotten
> password via email, ask for the password.
> This is just senseless. I forgot the password and I want it back. To
> have it back I should insert it? Didn't I forget it?
No, you misunderstand what I have written ;-).
The system should ask for the user password when the user wants to
change its email address.
This is important *if* the system allow an user to ask for its forgotten
password and this is sent to its email address.
An attacker (that obtained a valid session ID) can change the account
email address and ask for the password!
> Line 90:
> IMHO this section is not clear enough (if at all).
Well, I just put in some things I have read, without some review.
However note that I'm considering HTTP Basic Authentication without
sessions, so an user is required to supply credentials for every resource.
This means that there is no support for anonymous user.
> Session section:
> subsection you say that this approach has several flaws?
Because, by design, sessions are not good for authentication.
However cookies based sessions are better that URL based sessions or
form based sessions.
The only flaw of a well written session management system (as I can
understand) is a replication attack (done by someone that can see the
traffic beetwen client and server).
This assuming that one isn't using permanent sessions.
> Line 244:
> The difference between random/urandom is not that one returns a string
> and the other doesn't. urandom uses /dev/urandom on UNIXes (not
> available on Windows) while random.random uses a pseudo random number
I'm not saying this (but I must explain better the difference beetwen
urandom and random).
Really, there I'm asking: "why to use a float number?" ;-)
> Line 404:
> The "Remember Me" feature is more than that. It's a persistent session
> and cookie.
Ok, I have to add some more words.
> A persistent cookie for a day or so can be used when a
> simple login is done. Transient cookies and session for anonymous sessions.
> Line 41x:
> This looks WAAAAAAY too paranoid for the real risks. Just use HTTPS is
> you are so scared of people stealing other's passwords.
No, because HTTPS **is not** needed to keep user's password safe.
It is only need for the login page.
> I don't think it's safe to show code in sandboxes in documentation. That
> code is in sandboxes for a reason. Also the session.py "example" is not
> very tested and should not be used as a reference implementation.
Ok, but I just don't want to add too many code in the document ;-).
> should explain what a "smart" load balancer is (stateful?).
This comment should go away!
The load balancer of Lighttp is not as "smart" as I was hoping.
It just can generate an hash over the request-uri and make sure that the
same request URI is sent to always the same host.
> The most powerful feature of guard is being able to write the
> authentication code once and reuse it forever. You can return different
> resources even without it.
I just have to say that guard *is* cred integration (maybe adding an
example of usage).
> guard is not **very** complex. guard is actually pretty transparent for
> the userlevel code, that's exactly why it is like it is.
> The current guard does not login into the realm each time.
> That's an
> optimization. And the custom dynamic request is done for every
> locateChild method call togheter with tons of Contexts.
I can create a complete "static" site, with all Resources created at
Of course I can always cache Resources on the portal.
Maybe I need to add some examples.
And I would like to do some benchmark to understand the cost of creating
every resource object on the fly.
> This is (or should be) a Nevow specific document. Not talking
> extensively about guard is a sign that it is not yet complete.
You are right: but when writing the document I totally forgot about
> The code
> that doesn't use it in the rest of the document is good to explain what
> guard does and not to avoid using it.
This is what I want.
> guard is not only more flexible,
> but also more tested and more functional than most of the ad-hoc code.
And guard has some (avoidable) security problems, too...
It uses URLs based sessions without my permission.
> It is also made to avoid changing ANY application level code just
> because you are adding authentication.
Yes, this is a great thing.
> It is also made to be easily
> added to an existing Twisted application since it would reuse the same
> portal/realm removing the need to write that code.
Here I'm really curious.
Is cred + guard really so reusable?
As an example, how easy it is to write an integrated authentication code
(as an example on Windows's Active Directory)?
> guard user level API
> is also arguably simpler than writing an auth solution for any of your
The session handling code can be factored out in a Mixin class.
This mixin only have to check for a session and, if available, to set
the username attribute on the request object (or None, if no session
Of course I can reuse your Session Manager class (this is why I like it).
Maybe I would prefer to factor out the cookie handling code (an
This allow one to write custom code, as an example one can create an
additional cookie with a signed and crypted client address, using the
Or, more paranoic, one can create an additional cookie with a signed and
maybe encrypted serial number.
This number is incremented at every request (both on the session cookie
and on the session object) and checked.
> This document needs a grammar review.
More information about the Twisted-web