isLonely() does not solve the security issue

[mipo256]

The page that describes the solution provided by the isLonely() function is actually a bit wrong in the sense that this does not really solve the security issue.

For instance, a Book may have a field createdBy, which should be, for instance, determined from the current session of the given HTTP request. The problem is that this field is a scalar in terms of the Jimmer terminology, and therefore isLonely() would not complain about the fact that the client either accidentally or intentionally set the createdBy by himself.

So I think the warning in the docs is great, but we cannot really say that if the relations are unset or set to ID's only, then the operation is secure. It is not like that. It should be mentioned.

[babyfish-ct]

Any suggestion?

[mipo256]

The suggestion is to rephrase this in the documentation. I'll provide the PR.

[mipo256]

To be honest, I even think that if this approach does not solve both the API ambiguity problem and the security issue, then do we really need this solution at all?

It seems that if the user is just playing around, he does not need that at all. Alternatively, if he is dead serious about the consequences, then he must've handles both the security and API ambiguity issues. So it seems that the best thing to do here is to deprecate this function for removal and mark this in documentation.

CC: @babyfish-ct

[babyfish-ct]

No, isLonely is only used to check whether it is a single object, not a data structure. This is a simple, basic, theoretical, and business-independent auxiliary method.

For security of input parameter of business entry, DTO language supports InputDTO