How to protect Python source from modification
Philippe C. Martin
philippe at philippecmartin.com
Tue Sep 13 00:24:50 CEST 2005
Why not just releasing the *.pyc ?
Frank Millman wrote:
> Hi all
> I am writing a multi-user accounting/business system. Data is stored in
> a database (PostgreSQL on Linux, SQL Server on Windows). I have written
> a Python program to run on the client, which uses wxPython as a gui,
> and connects to the database via TCP/IP.
> The client program contains all the authentication and business logic.
> 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.
> The only truly secure solution I can think of would involve a radical
> reorganisation of my program, so I am writing to see if anyone has a
> simpler suggestion. Here is the idea.
> 1. Write a socket server program that runs on the server. The socket
> server is the only program that connects to the database. The client
> program connects to the server, which authenticates the client against
> the database and then listens for requests from the client.
> 2. Devise my own protocol for communication between client and server.
> For selects, the client sends a request, the server checks permissions,
> then retrieves the data from the database and passes it to the client.
> For updates, the client passes up the data to be updated, the server
> checks it against its business logic, and then updates the database.
> 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. If on the client, I would have to reorganise my
> thinking even more, but this would have an advantage - I will
> eventually want to write a browser interface, and this would be much
> closer in concept, so the two approaches would be quite similar.
> 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
> 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.
> Frank Millman
More information about the Python-list