Frank Millman wrote: > Hi all > > I am writing a multi-user accounting/business system. Good!
> The client program contains all the authentication and business logic. Not good. You lose...if it's *only* in the client. Of course, there is no such thing as a safe system, and you need a pragmatic approach to deciding a level of security. For a system like this, I'd certainly prefer to design the system so that it's immune to modifications in any software running on a machine that isn't "safe", such as a typical end user PC. IOW, no direct DB access allowed (at least not with anything but select permissions) and all authentication and security related verifications etc in a server process which isn't available to ordinary users. However, such schemes aren't immune to flaws. First of all, there might be mistakes in the implementations (how ever cleverly they are made) and there are always people who have access to servers and databases. You need audits and checks on various levels to handle such things. You can probably get transaction logs for the database system to be stored on some other server, which might make it more difficult for someone who manipulates the system to hide their tracks. All external transactions (especially payments from the system) need to be audited and scanned for irregularities. Can all payments be traced back to valid business transactions? Are there patterns in payments that stick out, such as many small transactions to the same receiver? Security checks like these should probably be made completely outside your accounting/business software, and by people who have nothing to do with your main system. Regardless of your intentions, there is no way you can stop people from hurting themselves. The customer of the system will basically set a ceiling for the security of the system, depending on how ambitious they are, and what kind of infrastructure they can provide etc. Small customers might well demand perfect security, but they probably don't want to pay for it. > It has dawned on me that anyone can bypass this by modifying the > program. As it is written in Python, with source available, this would > be quite easy. My target market extends well up into the mid-range, but > I do not think that any CFO would contemplate using a program that is > so open to manipulation. Just distribute zipped library instead of .py files, and you've raised the bar to the same level as if you've written it in Java. I.e. it's as if you send your mail in envelopes (just not glued together) instead of in postcards. No one will accidentally see the source code, but the persistent user can. > There is the question of where state should be maintained. If on the > server, I would have to keep all the client/server connections open, > and maintain the state of all the sessions, which would put quite a > load on the server. Really? How many users do you imagine? How would you plan to organize your servers? One process per connection, one thread per connection or asynchronous processing in one thread as in Twisted or asyncore? Perhaps you should have a look at Twisted ot asyncore? > This raises the question of whether I should even bother with a gui > client, or bite the bullet and only have a browser based front end. > Judging from recent comments about new technologies such as Ajax, a lot > of the disadvantages have been overcome, so maybe this is the way to > go. It's still a big difference, isn't it? Have you seen a web based accounting system that you thought was good enough? > It would be a shame to scrap all the effort I have put into my > wxPython-based front end. On the other hand, it would be pointless to > continue with an approach that is never going to give me what I want. > Any advice which helps to clarify my thinking will be much appreciated. A wxPython client and a Twisted server might well be a useful combo. If you have well written Python modules for validating data etc, you might just run them in both client and server to achieve instant feedback on the client without lowering the security bar. A budget solution if you want to keep a simple fat client / thin server solution is to run the clients on a box that the end users can't manipulate. Just let them access that box via VNC and only run this client program there. It's not completely trivial to set up such a safe environment though, but it basically gives you an application server and very thin clients that still give you the same rich UI as wxPython on their desktops. They'll have to get used to a non-Windows GUI though, unless you choose to run Citrix instead of VNC (or use one application server per user :). -- http://mail.python.org/mailman/listinfo/python-list
