Kbase P71263: Why Security based on fields is not working at RUN-TIME the
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
12/03/2004 |
|
Status: Unverified
GOAL:
Why Security based on fields is not working at RUN-TIME the same as at COMPILE-TIME
GOAL:
Field Security behaviour
GOAL:
Compile-time Security
GOAL:
Run-Time Security
CAUSE:
If I put on DB admin security on a field, allowing an user to be able to update a field (lets say Country on Customer table).
From the procedure editor if I do while login with a non authorized user:
For each cust:
update country.
end.
The Field security will pop-up a message with insufficient access privileges.
However if the procedure is compiled, anyone can access the field and no security on field will raise.
FIX:
This dates back to the time when we had very limited memory and could not cache any field level information including security.
We certainly could not got to the database for that information during runtime updating.
So we simply checked it during compile time on the theory that you would limit your runtime users to only using .r's and the .r could be protected by file system security, or by the CAN-DO facility which takes a userid and password.
In dynamic programming, (e.g. buffer-field-handle:BUFFER-VALUE = xxx, or buffer-handle:RECORD-DELETE) we do runtime security -- that is we cache all the field information for any dynamic buffer, and look at the security information at runtime, so your program below, if converted to dynamic, would compile ok but would not run.
Also, note the following:
The scheme we have is quite flexible. You don't always want the checks to be made at run time. Sometimes you want the application to control security by arbitrary rules that it has programmed into it.
For dynamic queries, we also check at compile time, but it is when the /query/ is compiled (i.e. during the query prepare) while the program is running. So you get run-time security checking for dynamic queries.
One thing we don't have that would be nice is to be able to define views in the 4GL and for the security to be defined on the view rather than the underlying base tables.
This technique is common in SQL-based applications.