Problem revoking permissions in custom RDBMS realm implementation
Greg Taylor
management support) in WebLogic 6.1 sp1 and when trying to revoke a
permission on an ACL that I created using the WebLogic console, I got
the following error page:
Error
Couldn't revoke permission ORDER_VIEW for GREGT to MyAcl
--------------------------------------------------------------------------------
weblogic.management.internal.RemoteRealmException: Couldn't revoke
permission ORDER_VIEW for GREGT to MyAcl
at
weblogic.management.internal.RemoteRealmManagerImpl.revokePermission(RemoteRealmManagerImpl.java:296)
at weblogic.management.configuration.Acl.revokePermission(Acl.java:82)
at
weblogic.management.console.actions.realm.DoAclPermissionFormAction.perform(DoAclPermissionFormAction.java:139)
at
weblogic.management.console.actions.internal.ActionServlet.doAction(ActionServlet.java:167)
at
weblogic.management.console.actions.internal.ActionServlet.doPost(ActionServlet.java:85)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:265)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:200)
at
weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:2456)
at
weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2039)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
--------------- nested within: ------------------
weblogic.management.configuration.RealmException: Acl.revokePermission -
with nested exception:
[weblogic.management.internal.RemoteRealmException: Couldn't revoke
permission ORDER_VIEW for GREGT to MyAcl]
at weblogic.management.configuration.Acl.revokePermission(Acl.java:84)
at
weblogic.management.console.actions.realm.DoAclPermissionFormAction.perform(DoAclPermissionFormAction.java:139)
at
weblogic.management.console.actions.internal.ActionServlet.doAction(ActionServlet.java:167)
at
weblogic.management.console.actions.internal.ActionServlet.doPost(ActionServlet.java:85)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:265)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:200)
at
weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:2456)
at
weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2039)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
I see several calls to my realm (getUser, getGroup, getPermission) in
the trace, but these calls have completed by the time the above stack
trace is generated. I had a similar problem when trying to change a
user's password until I found the CredentialChanger interface, so is
there a similar interface that I need to implement in order to revoke
permissions? Any help would be appreciated.
Thanks,
Greg Taylor.
--
To reply to me personally, please replace SEE.SIG with octanewave in the
above email address.
Greg Taylor
Jerry wrote:
> Hi Greg
>
> Sorry about the empty post. I do that far more frequently than anyone ought to.
>
> Hopefully the following explanation will help you to write some code so that you can remove users/groups from an
> ACL:
>
> Someone writing a custom realm not only implements the Realm interface, but is also responsible for implementing
> the Acl & AclEntry interfaces. WebLogic provides default implementations of the Acl & AclEntry interfaces - that
> is, AclImpl and AclEntryImpl. These classes are responsible for holding the acl info in memory. They also have
> methods for modifying the acl.
>
> The RealmManager adds a permission by calling "setPermission" on the realm. It removes a permission by completely
> different means. First, it gets the acl and finds the acl entry that contains the user to be removed. Second, it
> makes a call on the acl entry to remove the permisson for that user. Third, it makes a call (removeEntry) on the
> acl to remove the acl entry. Fourth, it make a call (addEntry) on the acl to add the modified acl entry back in.
> Again, all these calls make in-memory changes - they do not write out anything to disk.
>
> So, to write the acl changes out to disk, you should derive a class from our AclImpl class and provide a
> implementations of the addEntry and removeEntry methods which call the super class (to make the in-memory
> modification) then write the acl out to disk. You can use the public acl methods to get the in-memory state so that
> you know what to write out to disk.
>
> Note: when you originally construct the acl in memory for the first time (for example, you're reading it in from
> disk), you are probably calling addEntry. You probably don't want to be writing the acl out to disk at that time!
> So, you need to make your AclImpl class smarter - that is, aware of when it's being constructed vs. modified.
>
> For example:
>
> class MyAclImpl extends AclImpl
> {
> public ... addEntry(...) // the public api
> { // the public api is only used for modifications
> // therefore write the changes out to disk ...
> internalRemoveEntry(..., true);
> }
>
> private ... internalRemoveEntry(..., boolean writeToDisk)
> {
> // first make the in-memory changes:
> super.removeEntry(...);
> // now, write the changes out to disk if appropriate: if (writeToDisk) ...
> }
> }
>
> When you are loading the acl from disk, make sure to call acl.internalAddEntry(..., false) instead of
> acl.addEntry(...)
>
> By the way, if you use this hook (add&removeEntry) to write acl changes out to disk, then you don't need to do it
> for Realm.setPermission.
>
> Hope this helps,
>
> Joe Jerry