secure script advice

[sysadmin42]

I wrote a script that is pretty cool in its function. Here's the overview: you have a db form page and on this page there's a hidden <iframe>. When you update a field in the form (onchange='update_database(...)'), javascript calls a page into the iframe that runs an update query. This saves having to click a button to update- especially nice for long forms where you risk losing all the data you just entered!

It's running on an internal intranet with a 1Gb backbone and it works like a charm.

By itself, passing a query to the hidden script is easy enough. But I have user permissions and login cookies. It's easy to have the script secure against those who are not logged in, but I need to process for permissions.

Right now, I just have several different scripts for different functions and permission blocks on each script. This is cumbersome- I really need to simplify into one script.

So... what I need your help with is simply an architectural approach to this idea. What pointers can you give for simplifying this? Your advice is much appreciated.

"Computer illiterate is a dirty word."

 

[jpadie]

i thought i'd already replied to this thread. strange.

I'm curious: why use iframes rather than xmlhttprequest (ajax)?

anyway - the nub of your question relates to authorisation. sfaik there is no neat trick to avoid testing for the appropriate permission at each function (used at a business level rather than coding level although the two often overlap somehwat). i.e. you have to test the intersection of a userid and permissionlevel.

from an architectural point of view it can easily be one function that provides this analysis and the function is not difficult provided you set up your permissions ok. and here is where it gets tricky.

for a simple architecture you could decide on a small number of classes of user: i.e. viewer, editor, administrator and against each user in the database you'd store another column with a value for each of these. For these types of solution i store the user's security level as a session variable to avoid db calls for each function. so you'd test in each function for $_SESSION['userlevel'] > X where X is 0, 1 or 2 for view permissions, edit, admin etc

but often you need a full access control list structure. the architecture of this depends on your needs but more often than not I fudge things slightly by creating "groups" of users and storing those as if they were an actual user. i then create a separate lookup table to hold the joins between users and groups of users. in this way you can assign access to entities at a completely granular level or easily by clicking on a group. unjoining a member from a group removes the user's access to the resource.

of course you also need a table to carry the permissions between the resource and the permitted users. typically i also include a deny column too so that if i have granted rights to all "Management" i can deny access to a particular member of that group (for example the resource might be a conversation thread about firing that person). Deny columns ALWAYS overrule persmissions...

Management of ACL's requires a really rigorous and restricted user interface so that people don't assign the wrong permissions and do stupid things. I have always found that the planning of the structure takes at least as long, if not more so, than the coding of it.

you might take a look at PEAR::LiveUser which has a permissions structure from memory. But beware, it is a heavyweight package with a bit of a learning curve.

 

[sysadmin42]

good thoughts. thanks. I was unaware of xmlhttprequest. I used iframes because that's what I knew of... i'll do some learning on that subject.

"Computer illiterate is a dirty word."