User permissions

[bulklodd]

As you know PROGRESS keeps user rights for tables in the fields of '_file' table as comma separated lists. We've got a problem with the size of these fields. Our customers have a lot of users in their DBs and often these lists exceed 32K. Now I'm considering some solutions:
- refusal of keeping user lists in these fields to make user rights checking in the application only
- compression these lists, e.g. 'aaa,aab' list will be substituted for 'aa*'
- substitution of all current userids by short ones.

I'd like to know another solutions and what solution is the best or common?

TIA

 

[Lee Curzon]

I don't think compression will work, because at some point the field will overflow again.

Do you need to control access on a table basis, or can you just assign users access to parts of the application as required (ie. track from within - which I tend to do)?

You could combine the two by logging into seperate applications via a role stored in the user table (eg. Admin), with table access determined by the role, then have the 'proper' user login handled by the app with further access rights checking.

Just some thoughts off the top of my head...

 

[bulklodd]

Thank you, Lee

Do you need to control access on a table basis, or can you just assign users access to parts of the application as required

No, I don't but I deal with a legacy application and I can't imagine all consequences if I get rid of these lists. Anyway it's the simplest way for me.

You could combine the two by logging into seperate applications via a role stored in the user table (eg. Admin), with table access determined by the role, then have the 'proper' user login handled by the app with further access rights checking.

I like this solution and I think it's the proper way. But in this case we'll have to rewrite and retest a sizeable part of our application. I'll think about it in more detail.

 

[Lee Curzon]

Another (kludgy) way is to implement database/session triggers and check there, but I suspect this is not manageable with a large number of tables. Too slow probably, and not the correct way I think.

When business logic is separated and well managed, the problem shrinks dramatically, because there are only a few places to check - but this is unlikely to be of much use to you if you are dealing with scary legacy stuff.