I managed to reproduced in a simple test case with 1 entity Jobs on an editable table.
I have enabled security and I have 2 roles ‘UpdateJobs’ and ‘ViewJobs’.
I have added authorisation to entity update and delete for role UpdateJobs.
When I loggin with a user that just have ViewJobs role table rows comes read only and Delete button disabled.
Yet CreateInsert button is enabled and if I press it new row is created with updatable attributes that I can also save it without a problem.
Before last patch you could still create new row but it was not updatable.
Is this a bug?
Test case:
http://adfbugs.googlecode.com/files/TestInsertSecurity.zip
password for User and Manager : welcome1
Hi Michael,
ReplyDeleteGranting (or denying) update permission is not supposed to cover insert permission as well. We didn't add insert permission to the entity object authorization dialog, partly because unlike the other operations, insert isn't something you do to an existing EO instance; and also because we found that people's requirements were slightly more complicated and best defined by the application developer. For example, developers often want to allow or disallow creating a new child entity on a specific parent EO.
To control the enabling or disabling of your CreateInsert button you could access the security context via EL (#{securityContext.userGrantedPermission['...']} etc) or you could write a client method on your appmodule or VO, create a method binding and call the method via EL.
Hope this helps.
Blaise, Oracle Product Management
Hello Blaise.
ReplyDeleteThank you very much for your responce.
Yet i am a little confused. Does this mean that it was a bug before and now it is fixed? can i have the bug reference?
Also a common requirement that we have is for some users to just have read access on entities that others can insert, delete and update. Not being able to declarativly do that anymore in model layer is a loss of functionality and reusability, dont you think?
Michael,
ReplyDeleteYou could consider the earlier behavior a bug, but I don't believe it was ever logged.
ADF security in 11g is implemented at the application level. We found that users typically design security for their whole application so it makes more sense to let them define permissions on task flows and pages, although we do have the blanket EO security that you have been using. Working at the task flow and page level you can define how you want your application to behave depending on the current user's permissions. I don't think there's any loss of functionality.
BTW would you mind changing the header of this article, since it's not a security hole or a new bug.
Thanks
Blaise
Thank you Blaise, I changed the title.
ReplyDeleteYet I feel this functionality change should be documented. The existing applications could be greatly effected by this change.
Also since entities are reusable, now you need to repeat the same functionality restrictions in all pages that they are used. The same does not apply for delete security restriction that the delete button automatically becomes disabled.
On the first TP releases you could declaratively add security business rules on many different levels (Entities, views, bindings, etc). I feel like as the patches come out the choices for declaratively defining security rules are being reduced.
Michael,
ReplyDeleteThanks for changing the header.
For discussions on features and functionality, it's better to use the JDeveloper discussion forum on OTN.
Thanks
Blaise