Making public accessors for fields of org.activiti.engine.impl.cmd.Command impls

[pkonyves]

Hi there,

Would it be possible to make fields in Commands (e.g. SetExecutionVariablesCmd) package private? I think Activiti has a great design with the Command pattern with it's interceptors, it is suitable to change/enforce business logic rules in a low level with interceptors, but every case is unique and the biggest burden is to acquire information from the Command object. If fields were at least package private, it would be much more easier to implement custom business logic with interceptors.

I actually think it would also make sense to create setters/getters for the fields in the command. They are not part of the public API, and are always subject to change, but with getters at least they were be more usable from CommandInterceptors.

What do you think?
Pal

[jbarrez]

We have the policy to make all our fields protected. Isn't that enough in case you want to override?

I'm not following your use case yet. What use case might you have that would need that?

[pkonyves]

Basically I want to implement authorization methods with command interceptors. This is a complex task, where the authorization rules would be defined in the bpmn. Use-cases would be: read-write permission on process variable; task/process listing restriction; task completion restriction etc… For this I need information from the command, but now the only way to get the for example the execution id from the command is to use reflection which is slower than direct access.

[pkonyves]

The main problem is that today is really easy to do anything via the rest interface, and right now I don't know how it is solved in e.g. Alfresco Activiti, I suspect it is not solved, which is a real security concern.

[k5_]

basic java: the protected access modifier includes package private.

[pkonyves]

So I just failed as a Java developer damn it..

[jbarrez]

> which is a real security concern.

I'm interested why you say that. I don't see how that can be a security concern.

[pkonyves]

I might miss something from the big picture, but as far as I know, if a user is allowed to access the REST interface, can basically do any operations on it. So if a single page web application uses the Activiti REST interface directly, a logged in user can access or even change information in e.g. process variables that he should not see. For example employees should not be able to see company management decisions/processes. Not mentioning starting and cancelling processes or accessing the repository API.

That is what I want to solve.

[jbarrez]

No sure, i can see that. But that needs to be solved by real security checks AROUND the rest calls.

Making a method public/protected/private/whatever has no impact at all on that.

[pkonyves]

Yes, I know, method visibility has no impact on security, is part of creating a solution. However as K5_ already mentioned protected is also package-private, so I can access the fields.

I want to create the solution in the BLL, not in the rest layer.