On Thu, 03 Aug 2006 12:17:03 +0200, Manlio Perillo <[EMAIL PROTECTED]> wrote:
I'm interested in this.
Are there any examples?
I would like to add a section on authorization, too.
The avatar object is exactly that kind of example. It contains all the needed
information to authorize it at application level through some locateChild level
mechanism.
There are many examples of that in stiq.
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?
To use sessions.
I think you are confused here... HTTPS and sessions are 2 totally different
things.
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?
No, you misunderstand what I have written ;-).
It's not very clear.
The system should ask for the user password when the user wants to
change its email address.
This is important *if* the system allow an user to ask for its forgotten
password and this is sent to its email address.
An attacker (that obtained a valid session ID) can change the account
email address and ask for the password!
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.
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?
Because, by design, sessions are not good for authentication.
sessions are not authentication, of course they are not good for that.
However cookies based sessions are better that URL based sessions or
form based sessions.
They are different kind of things. Sometimes clients don't support cookies. How
are you going to provide a usable website for them?
The only flaw of a well written session management system (as I can
understand) is a replication attack (done by someone that can see the
traffic beetwen client and server).
Just use HTTPS.
This assuming that one isn't using permanent sessions.
There is no such thing as permanent sessions. They might be persistent for some
time but not permanent.
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.
No, because HTTPS **is not** needed to keep user's password safe.
It is only need for the login page.
Much of the problems you are trying to find here are all resolved by using
https for everything in your website. I doubt it's worth to lose so much
developer time in trying to make secure something that cannot be secure by
design (there is a machine that is not under your control and that is also the
one you want to protect). Just use HTTPS for all your website. Safer and
simpler.
No.
I can create a complete "static" site, with all Resources created at
start time.
You can do _EXACTLY_ the same thing with guard. Did I mention that guard is
like it is to avoid changing ANY code in your application?
Maybe I need to add some examples.
And I would like to do some benchmark to understand the cost of creating
every resource object on the fly.
rend.Page() objects are made to be destroyed for every request. 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!) 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?
Here I'm really curious.
Is cred + guard really so reusable?
yes.
As an example, how easy it is to write an integrated authentication code
(as an example on Windows's Active Directory)?
IIRC Active Directory is pretty much LDAP. Which means that it's almost a
no-brainer.
The session handling code can be factored out in a Mixin class.
This mixin only have to check for a session and, if available, to set
the username attribute on the request object (or None, if no session
exists).
Requires changing the application code which might not react as expected to the
mixin.
This allow one to write custom code, as an example one can create an
additional cookie with a signed and crypted client address, using the
same interface.
Or, more paranoic, one can create an additional cookie with a signed and
maybe encrypted serial number.
This number is incremented at every request (both on the session cookie
and on the session object) and checked.
This looks so paranoid I can't believe anyone could use it... Why should I need
such a secure way of communicating through the web? there are already other
kinds of mechanism that are even more secure than that. I think HTTPS, secure
cookies and encrypted cookie values are more than enough to barely trust a
cookie.
Anyway it seems reasonable to factor out the cookie handling stuff.
_______________________________________________
Twisted-web mailing list
[email protected]
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
