On Thu, 03 Aug 2006 18:28:04 +0200, Manlio Perillo <[EMAIL PROTECTED]> wrote:
Of course.
Is this better?:
"""Session cookies carry some text used to authenticate users (called
authenticator).
The only secure way to transport such an information beetwen client and
server is with HTTPS."""
This is better. Although 'carry some text used to' is not that good, what would
be good is to write that it carries _exactly_.
This is a non-problem with my guard. Asking authentication each time
invalidates the current session credentials (because you changed the
password in the database when you autogenerated a new one). To reach the
user pages again you'd have to know the autogenerated one. because the
one stored in the session is not valid anymore.
Not sure.
An attacker "authenticate" into the application using a stealed cookie.
No one is changing/regenerating the password, the attacker only changes
the account email address and then ask the system to send the
"forgotten" password to the new (under its control) email address.
It needs to execute HTTP commands, and the sessions does not change.
Given your other suggestions (one of them was store the hash of the password) how are you
going to send the "forgotten" password? You don't even know it.
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.
Anyway these suggestions are more part of another chapter that could be
titled: "Suggestions on safe web app design" rather than part of the
authentication chapter.
sessions are not authentication, of course they are not good for that.
Yes, sessions carry authenticators.
What are these and why?
They are different kind of things.
No.
Both cookies, URLs and hidden form's controls are a mean to transport
sessions IDs.
Those are _different_ means to transport session ID.
Do you prefer a fully usable site to a secure one?
Cookies are standards.
You still have to show me how it is not secure to use session IDs in the URL.
I don't have an e-commerce site.
Its only a portal.
You are spending more time here talking about how to make session id exchange
more secure while you could have simply used https and that's all.
Doesn't sound very efficient.
Mea culpa on using the wrong term. Of course I intended persistent.
persistent sessions are yet another thing and the user asks for the explicitly
by ticking 'remember me'.
I will do some test but HTTPs for every page is likely too heavy for the
poor server.
heavier than nothing, probably true
heavier than encrypting/decrypting all cookie values each time? slightly
heavier timewise? not at all.
Not sure.
I guarantee you!
The root resource is created only once, right?
You decide it.
And I can do:
class ChildPage(rend.Page):
...
class MainPage(rend.Page):
...
root = MainPage()
child = ChildPage()
root.putChild('a', child)
child.putChild('b', child)
server = appserver.NevowSite(root)
See? You can decide it, although if you did this because it was an optimization
you will regret doing it.
And this
will be enforced without the context. Also... Are you actually worrying
about creating one object compared to the cost of rendering a dynamic
page? (and locating it!)
I have learned to not make pre-assumptions without doing some tests.
well... I did tests and I know what happens during page rendering and page
lookup. For each rendering 6 to infinite contexts are instantiated. If you nest
more than 5 fragments python reaches the infinite recursion limit (this number
might vary, just to give you an example of how many objects are created during
rendering). You are removing a:
[EMAIL PROTECTED] /Volumes/dati/Sviluppo/Divmod/branches % python -m timeit -s
'class Foo(object): pass' -c 'Foo()'
[17:31]
1000000 loops, best of 3: 1.62 usec per loop
1.62 usec (on my ibook)
over something that is extremely more expensive per se (child lookup).
Of course there's nothing that prevents you to
return always the same page object from guard.
And guard has some (avoidable) security problems, too...
It uses URLs based sessions without my permission.
my who? user? developer?
Developer.
Can't see that as such a big problem... But it should be configurable indeed,
open a ticket.
Some sites, as an example, bind cookies to user IP address (Yahoo, at
least some years ago).
Which is not secure, I can fake it, I might be behind a NAT, I might steal the
computer, I might use a computer from an internet cafe` used by someone else
before me. How is this going to be more secure? HTTPS is enough.
Some other personal advice about yout guard implementation:
- I think that SessionManager should be renamed SessionFactory
It's not a proper factory. SessionManager is a clean name, it manages lifetimes
and creation/destruction. Exactly what a manager does.
- Maybe the getSession() of the SessionManager class should be changed
in getSession(sessionInterface=ISession)
That is, ISessionManager should work a little like the
ICredentialsChecker.
I can define an IGuardSession with additional features (the guard
attribute that really make sense only for authenticator's sessions.)
what's an authenticator's session? This might be useful but seems like a lot of
added complexity for a pretty small usecase. Remember sessions are an
implementation detail not something that should be exposed to the user. I can't
imagine a need for such a generic API.
- 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.
_______________________________________________
Twisted-web mailing list
[email protected]
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
