16.07.2001 19:17:44, "Remy Maucherat" <[EMAIL PROTECTED]> wrote:
>> I've changed AbstractStore.grantPermission() to check whether a
>> permission exists before creating it. I'm not sure whether that's
>> the appropriate place for the check, though.
>>
>This shouldn't happen. The security helper already has that
>particular code, and the XMLUnmarshaller which is loading the node is
>calling the right method in the security helper (grantPermission
>(token, permission)).
>
>The only permission which is using direct access for creation is
>permission /,/,/ created in Namespace. We should check if it exists
>(but it shouldn't).
well, that doesn't seem to be the actual problem here.
I'm having a hard time tracking the problem down... I think it's
something to do with the caching performed by StandardStore, but
that's a shot in the dark actually.
the permission that fails to get created is "/-root-/actions-true"
(and I assume any other permission on the root node would fail too).
SecurityImpl.grantPermission() _does_ check whether the permission
already exists, but JDBCDescriptorsStore.enumeratePermissions() is
never called at that point, instead the enumeration that is used for
the comparison only contains "/-/-/-true" (i.e. the temporary all-
access permission).
btw: the ServiceAccessException thrown by the JDBC driver at this
point is caught at servlet-level, it seems it should be caught quite a
bit earlier (XMLUnmarschaller maybe?). in addition, it leaves the
database in a bad state because the /tempaction object and the /-/-/
permission both still exist (those get created/removed outside of the
transaction).
-chris
________________________________________________________________
[EMAIL PROTECTED]
