[Twisted-web] [Nevow] new chapter about authentication

Valentino Volonghi aka Dialtone dialtone at divmod.com
Tue Aug 1 19:55:06 CDT 2006

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.

Line 13:
stateful is totally wrong and the opposite. Should be stateless.

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.

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?

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. The simple example is good although with guard it's even less than that.

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?

Line 90:
IMHO this section is not clear enough (if at all).

Session section:
Why is it suggested to use cookies when at the end of the same subsection you say that this approach has several flaws?

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 generator.

Line 404:
The "Remember Me" feature is more than that. It's a persistent session and cookie. 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.

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. You should explain what a "smart" load balancer is (stateful?).

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.

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.

This is (or should be) a Nevow specific document. Not talking extensively about guard is a sign that it is not yet complete. 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. guard is not only more flexible, but also more tested and more functional than most of the ad-hoc code. It is also made to avoid changing ANY application level code just because you are adding authentication. 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. guard user level API is also arguably simpler than writing an auth solution for any of your applications.

This document needs a grammar review.

More information about the Twisted-web mailing list