RTC: credentials running extensions
I wonder under which credentials are RTC plugins/extensions run.
I mean: if user X (who can or cannot do several operations according to his roles) executes an action and that action triggers a RTC extension, are the operations executed by the extension subject to the role-based limitations?
A concrete example: suppose that user X cannot edit attribute A on a work item (because his roles forbid him to do); if the extension triggered by user X tries to update attribute A, will it succeed?
I suppose that, if the extension runs with the "current user" credentials it will fail; if, instead, it runs under generic "jazz administrator" (i.e. super user) credentials, it will succeed.
I made some tests, and it seems that they run as "current user", but I need a confirmation.
My RTC version is 4.0.6
I mean: if user X (who can or cannot do several operations according to his roles) executes an action and that action triggers a RTC extension, are the operations executed by the extension subject to the role-based limitations?
A concrete example: suppose that user X cannot edit attribute A on a work item (because his roles forbid him to do); if the extension triggered by user X tries to update attribute A, will it succeed?
I suppose that, if the extension runs with the "current user" credentials it will fail; if, instead, it runs under generic "jazz administrator" (i.e. super user) credentials, it will succeed.
I made some tests, and it seems that they run as "current user", but I need a confirmation.
My RTC version is 4.0.6
Accepted answer
Participants/follow up actions, advisors and providers always run with the credentials of the user doing the operation. This has been discussed here several times already actually.
And it is not possible to cheat and gain root permissions. This would breach all security and is not possible.
And it is not possible to cheat and gain root permissions. This would breach all security and is not possible.
One other answer
I'm running 4.0.6, and it runs in the context of the "current user". I have found no way for it to run under any other context.
We've looked at triggering a servlet from the SSP that runs under a "special" context that could then update the work item accordingly in one situation where this is needed, but we haven't implemented that yet.
Susan
We've looked at triggering a servlet from the SSP that runs under a "special" context that could then update the work item accordingly in one situation where this is needed, but we haven't implemented that yet.
Susan
