[Twisted-web] [Nevow] new chapter about authentication
manlio_perillo at libero.it
Fri Aug 4 05:34:53 CDT 2006
Valentino Volonghi aka Dialtone ha scritto:
> On Fri, 04 Aug 2006 09:56:16 +0200, Manlio Perillo
> <manlio_perillo at libero.it> wrote:
>> 1) The client ask to change the password
>> 2) The application ask the old password and the new one
>> 3) do the query:
>> UPDATE Accounts SET password=md5(:new_password)
>> WHERE password=md5(:old_password)
>> The application developers can forget to invalidate the "old" session.
> I remember you said the problem was stealing the password. I can't see
> how this is going to allow stealing the old password.
Yes, you are right. I'm a bit lost within the discussion.
The right query is:
UPDATE Accounts SET password=md5(:new_password)
The attacher does not know (and it never needs to know) the "old" password.
It can simply ask the system to send a valid password to its email address.
>> So this means that the development of new guard is goind to happen in
>> Nevow and *then* ported to web2?
> Yes, unless web2 discovers a new and wonderful way to deal with this
Well, much of web2 developers are nevow developers. I'm wrong?
>> You can need to initialize some state in your Session.
>> class ICounter(Interface):
>> class CounterSession(Session):
>> def __init__(self):
>> self.count = 0
>> sc = SessionManager.getSession(ICounter)
>> I can now use this simple session to limit logins attemps.
> This usecase is not a very good example of why it is a good idea.
I'm not an expert in this field, so I have used the first example that
come to my mind.
> But I think it may be required for OpenID and similar mechanisms.
>> But I can bind the session to the source IP address, using this value as
>> session key
>> (at least I would like to send an email to the site admin when having
>> 100 logins attemps from the same IP address).
> I can't think of this feature in a pluggable way. If you want it just
> code it in your Session object. It's fairly easy to do.
Yes, but you have to handle the initialization code by hand
(self.count = 0).
>>> This is not enough reason anyway. You have to explain why it is a bad
>> I don't like the idea to have "authentication only" sessions.
>> SessionManager (and CookieFactory) is a general class that should not
>> live in guard.
> Any _technical_ reason? importing a module and getting only the objects you
> need from it doesn't sound so bad to me.
Handling session initialization code better.
Only SessionManager knows when a session object is created and when
simply retrivied (the interface is the same: getSession).
Regards Manlio Perillo
More information about the Twisted-web