Alessandro Vesely writes:
Sam Varshavchik writes:
Alessandro Vesely writes:
Sam,
I've rearranged the child code, it now can save
cache files bigger than 2k. It doesn't appear to
be running better or worse than before, but it
will be interesting to save more stuff in some
cases. E.g. save what was the user request before
revalidating a session by forcing a login,
so that we can jump stright back there
(if sucessful).
That's a big no-no. Something like that opens up a potential
denial-of-service attack, where the attacker keeps sending bogus requests
that are saved in the login cache, causing it to grow without bounds.
One should not have more than one cache per user,
so the d-o-s attack wouldn' really exceed much the
planned system size.
You don't know whether the specified userid is valid without checking
against the authentication database. And the whole point of the login cache
is to avoid checking the authentication database in the first place, for
every HTTP request.
Congratulations. You've just DOSsed the box by flooding it with bogus HTTP
requests that causes it to overload the LDAP or MySQL authentications
server.
Also, a second unauthorized
request from the same user should be refused, because
Random userids for every bogus HTTP request.
Think "SYN flood".
People sitting inside nested folders also gets
annoyed with the timeout. You know that better
than I do. Don't you agree it is the biggest
limit of SqWebMail?
No. I never have a problem with the timeout.