Restrict write access to one method

[BulldogBen]

I'm writing an accounting module for our solution, using the great advice from here: http://homepages.tcp.co.uk/~m-wigley/gc_wp_ded.html

I want to be sure that my PostEntry() module is the ONLY module in the whole solution that has write access to my posting table. Further to this, I would like to ensure that only my EnterJournal() method can call my PostEntry(), and no others.

Apart from remembering not to write any other functions that try and write to this table, is there any other way to restrict write access to this table to just this one method? I'm new to OO programming, is this something to do with inheritance, exposure, etc?

Thanks in advance

[BulldogBen]

Either I've asked a really good, or a really stupid question - judging by the lack of response!

[ptalbot]

Either I've asked a really good, or a really stupid question - judging by the lack of response!

Most probably no one has ever had this kind of requirements, which would only be possible with quite a lot of programming.

One route that I can think of would be to use table events (onRecordInsert, onRecordUpdate, onRecordDelete), where you will have to set a parameter (a global variable for example) stating which method is asking the permission to act on that table, and perform the action or deny it depending on that parameter.

But usually, security is build on roles (groups) and the kind of user logged in, not really the kind of method he is using.

[BulldogBen]

I like your idea of intercepting those events, makes sense, and would give me the tight method hierarchy I'm after.

Because it's an accounting system I need to ensure that all postings to the ledger are perfect. There need to be no missing records, no deletes, no modifications, and always at least two records added at a time so everything balances.

I just wonder what other sources of trouble there could be I haven't thought of. For example, even if I only give Read and Insert access to all groups (including Administrators) in the table security, I can still accidentally delete using the Select menu in the Smart Client when I have "mustAuthenticate" turned off at the solution level during development.

I guess what I'd like here is some suggestions as to other ways items could be tampered with, by me or anyone else. I already know that I should...

x Ensure mustAuthenticate is set in all production releases
x Have a good username and password set in the underlying database (Sybase)
x Disable the Select menu in the Smart Client so I can't accidentally delete records with Ctrl - E etc.
x Use transactions to ensure either complete postings or none at all.
x What other precautions against corruption of my table may I not know about?

I realise the production release has a different data set to my test data set on my development machine. However, I want to minimise the number of things I have to check before making a new release as I like to iterate often at the moment (my poor staff are guinea pigs!)

[jcompagner]

you seem to want to have security for the developer of the software instead of the user of the software?
thats a bit weird..

Maybe with a tableevent on the table you want to monitor you can monitor all the modifications for that table and do you stuff..

[BulldogBen]

Thanks Johan, I've got enough ideas to get me through now.

It's just that with a complex solution, and something as important as the integrity of the accounts record, I want to protect myself (and future co-developers) from our own stupidity.

Thanks for all the feedback

[ryanparrish]

What about locking it down at the database level? Have two connections to your database with two different SQL user accounts.

One account that all other programming tasks/forms/modules use (i.e. 99.99% of your solution) and that doesn't have INSERT/UPDATE/DELETE privs on your ledger table.
Then another connection that does have those privileges, call it something really blatantly obvious like "LEDGERONLY" and use it for the module that does your ledger work.

This way another programmer would have to *deliberately* use the connection for ledger writing, and if they use it in a spot where they shouldn't...beat 'em with a hose.


...j/k about beating them...well...maybe a little bit...

[jcompagner]

that last thing will not really work in servoy
For that you need to have 2 servers in servoy, pointing to the same database, so if you update through one, the other doesnt really know that so will not get data broadcast notifications and so on.