[mod_python] Protecting Web apps from to many simultaneous clicks/Hacking

> If you mean, 'how do I protect against someone maliciously trying to
> overload my server' then the throttling/bandwidth limiting suggestions
> already given are useful tools.  If you mean, 'how do I improve my
> server's performance to handle high load' then read on.

The reason I ask is a bit of both 'overload server' & 'improve server's 
performance'. Also it has a little of 'I want my program to run within 
certain design parameters, and it should do some simple checking to make sure 
it is running within those parameters'.

> Use caching.  If you've only just asked the IMAP server for the contents
> of message #404, there's no good reason to ask it again.  You could
> cache the messages, the message indexes, or even the entire output of a
> given request.

I have already used some caching. When listing the contents of an email box I 
cache the folder list, the message's ID in sorted order, and the current 
window (i.e. 1-20) message's 'from, subject, date'. As I continue, I am not 
sure where I am going to add more caching. The design of the email solution 
(webmail and server backends) is designed to have many small nodes running in 
parallel. It is not like I am going to have one IMAP server, with alot of web 
frontends hitting it. The design is to have a local 'IMAP frontend' on every 
web frontend. Thus, the 'IMAP frontends' contact the 'IMAP backends'. The 
communication between the IMAP frontends and backends would handle individual 
message caching. Also, it will probably do it alot more efficiently than I 
can.

> Also, you probably shouldn't be storing the 'current message position'
> in a session.  This implies that the user is only viewing one page at
> once, which in a lot of cases isn't true.  They might open a message in
> a new window or tab, for instance, and have two messages open at once.
> Which one is 'current' in that situation?
>
> A possibly better way would be to have the "Next" link, as generated in
> response to a request to display a particular message, also include
> information about which message should be considered the next message.
> For example, I would probably implement this as a method to display a
> message by ID, and for each generated display, include a "Next" button
> which generates a request to display message #(ID + 1).
>
> If the functionality of "Next" means "Next Unread" or some such, I'd
> probably generate a request to display the next unread message after
> message #ID, so once again, the knowledge about the 'current' message is
> tied to a particular display.

When I said 'Next', I meant the next button to display the next window of 
messages in the email box (i.e. showing messages 1-20 and then 21-40).
But the point you bring up is very valid, and brings up concerns for other 
ways I have used session variables. Guess it is time for another rewrite. For 
caching, do you have any suggestions ? dbm, external database, etc ?

> ... so yes, the general idea is sound.  Your implementation is a little
> flawed, however.

Yeah I knew it was flawed, I need a better understanding of the dynamics and 
workings of Apache/mod_python. I played around last night, and here is what I 
came up with.

if not sess.has_key('REQUESTS'):
	sess['REQUESTS']=1
	sess.save()
else:
	sess['REQUESTS']+=1
	sess.save()
	if sess['REQUESTS']>1:
		sess['REQUESTS']=0
		sess.save()
		req.internal_redirect('/python/error/manySessions')
		return

The '/python/error/manySessions' displays a quick little error, and there is 
an auto refresh of three seconds. After the refresh, the user sees the page 
they were looking for.