On Thu, 03 Aug 2006 20:26:13 +0200, Manlio Perillo <[EMAIL PROTECTED]> 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.
_______________________________________________
Twisted-web mailing list
[email protected]
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
