From: Geoff T. <gta...@me...> - 2001-06-18 13:06:45
|
At 12:34 PM 6/18/2001 +0200, Albert Brandl wrote: >Hi! > >I think I've found a problem with SecurePage.py. The information on valid >users is stored in a session object. For security reasons, sessions >expire after a certain amount of time. Unfortunately, SecurePage does >not take this into account. > >This problem has occured when someone loaded data from a form, processed >them and tried to upload them again after the session had expired. The >Application presented him with a "session expired" message, but processed >part of the data, which leaved the whole system in a rather instable state >:-( > >I think these problems can only be avoided if any call to self.session() >is wrapped up in a try-catch-statement. I agree that there is a problem, but I disagree with your conclusion. It looks like SecurePage only protects the writeHTML method. But the sequence of method calls to handle a request is either: awake() writeHTML() sleep() or if an action handler is being invoked: awake() preAction() the action method gets called postAction() sleep() So if the user isn't logged in, SecurePage will still allow action handlers to be called, which is a huge flaw. And even for regular page requests, it will allow awake() to be called if the user is not logged in. Could this explain why your servlet processed part of the data? Anyhow, I think this can be fixed in SecurePage by putting the security mechanism into a _respond() method instead of in writeHTML(). You definitely shouldn't have to wrap calls to self.session() in a try/catch. If you want to try writing a fixed SecurePage it shouldn't be too hard -- I think you just have to move the writeHTML stuff into _respond. Otherwise I will get to it sometime in the next couple of days. - Geoff |