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

[Valentino Volonghi aka Dialtone]

On Thu, 03 Aug 2006 20:26:13 +0200, Manlio Perillo <manlio_perillo at libero.it> wrote:
>> You must autogenerate a new one and then send it, and if it's like that
>> you 'just' lost an account and not a password.
>>
>
>One can simply update the entry in the database, without having the
>application code know about this (but I'm not sure here, I have to do
>some tests since I'm interested in this feature).

Update which entry in the database? The password? Just ask to provide the old one or simply don't put the old one in the page. Again: how are you going to _show_ a passoword that you don't even know? it's hashed.

>authenticator or authentication token.
>On papers (like http://pdos.lcs.mit.edu/cookies/pubs/webauth:tr.pdf) and
>the OWASPGuide they use this term.

Ok, it's the session ID. Let's restate your sentence now then: you said that sessions are a bad fit for authentication.

This is true only when you talk about cookies. Sessions serverside are a perfect way to deal with authentication and they should not be accessible by the user.

>How many developers knows to remove meta tag in the body?

Well done even with the cookie. I think that a good way to fix the bug is
to begin some work to include my new guard code.

What do the others think about this? Glyph, exarkun, idnar, amberite, etc.?

>Well, know I'm spending a couple of hours on this topic, but HTTPs will
>slowdown my site forever.

Measured in how much loss in performance? How loaded is the server? How many users do you have?

>> heavier than nothing, probably true
>> heavier than encrypting/decrypting all cookie values each time? slightly
>> heavier timewise? not at all.
>>
>
>Encryption is not really needed, only signing.
>But, as you say, HTTPs can be a better solution at all.

signing is even heavier than encryption because signing means hashing and encrypting (a)symetrically which is what HTTPs does.

Many websites just go for the HTTPs solution with secure cookies. It's easy enough and if you were really concerned about performances you wouldn't be using python and twisted and nevow.

>Well, for some uses cases it can just work.

No it doesn't. It's mostly always a bad idea and is confusing.

>But this is a nightmare! ;-)
>Have you done some tests with the new version context-less?

context-less doesn't create contexts and that's more than enough to know that it would be better. Currently there is no code that uses a context-less rendering only an API that provides a Page and an Element object without the context.

>But you forgot to include some time here...

I expect you to do some job on your own. If you say something is expensive it's because you already measured it.

>But I think that it will never be commited, since it will involve a
>partial refactoring of Guard.

A new guard version is already there and we are about to start the biggest ticket in Nevow history... guard is not going to scare anyone (hopefully is going to go once web2 is finished).

>The same reason why old file upload support is still there (and there is
>no control on the size of POST data so someone can send me an image of 3
>MB).
>
>At least I can change this without changing source code.

Fixing this requires more than a simple refactoring... It's a complete overhaul of twisted.web API, which is twisted.web2.

>I can create a session only to store some state (as an example, to count
>how time an user failed the login).
>Why it should have a guard attribute?

Do you know that in python everything is by reference? It's not going to waste more time and having a reference to guard is useful for application level code that wants to mutate a session from unauthenticated to authenticated. (this is pretty much the only usecase).

>And, indeed, in newow.inevow are defined ISession and IGuardSession.

Those are not 2 kinds of sessions that you can use. It's backwards compatibility mess plus a small amount of being generic.

>You are right.
>But you are also supposing that SessionManager creates only one king of
>session.

I'm supposing that yes. Do you have a usecase besides the one already implemented in session.py where you have both persistent and non persistent sessions in the same object? 

>>> - If you choose to not create sessions for anonymous users, then there
>>>  is no more need for the loggedIn callback
>>
>> If you give me enough reason to remove the loggedIn callback I will
>> remove it.
>>
>
>If it is possible to avoid creating sessions for anonymous users, then a
>session needs only to be created after a successful login.
>So you can put the code that is now in loggedIn in createSession.

Which doesn't change the fact that createSession is not that easy to change while changing loggedIn just requires a subclass and override without even going for the upcall if you don't need to, because the callback is fairly easy (and that's why it's a callback).

This is not enough reason anyway. You have to explain why it is a bad idea.