This change will be compatible with some unforeseen policy in which values count less or longer than model tokens.
For example, If your policy definition is:
p = sub, obj, act
When we attempt to add the following policy, the old logic will ignore this action and return false.
Furthermore, because the logic for checking unexpected policies is executed after the Adapter is called, the database will contain this anomalous data, and it will never be able to be loaded into memory.
Starting from this change, the unexpected policies will be trimmed into the following expected format and can be smoothly added to the policy store. Of course, the return value will be true. Here is a simple test:
"alice", "data1", ""
"alice", "data1", "write",
This is a more gentle approach. Conversely, there is another option where we throw an exception for all unexpected policies.
But I believe this could be a change with high risk to the user. If the user prefers a more stringent method, we can provide an option for them to choose at later versions.
Why revert #337
Of course, it is also a method to address this issue, but its implementation logic is not very sound. It abandons the optimization of genericization and is unable to handle situations where the number of incoming values exceeds the number of tokens.
fixed: #335
This change will be compatible with some unforeseen policy in which values count less or longer than model tokens. For example, If your policy definition is:
When we attempt to add the following policy, the old logic will ignore this action and return false. Furthermore, because the logic for checking unexpected policies is executed after the Adapter is called, the database will contain this anomalous data, and it will never be able to be loaded into memory.
Starting from this change, the unexpected policies will be trimmed into the following expected format and can be smoothly added to the policy store. Of course, the return value will be true. Here is a simple test:
This is a more gentle approach. Conversely, there is another option where we throw an exception for all unexpected policies. But I believe this could be a change with high risk to the user. If the user prefers a more stringent method, we can provide an option for them to choose at later versions.
QA:
Do similar issues exist in other languages? The Golang version will exist, but its behavior will be somewhat different. It allow to add the unexpected policies to memory store, but will return an error when loading policy. https://github.com/casbin/casbin/blob/64efe3d122bfe68c9cf68e1bd174173a61f11743/model/policy.go#L155-L176
Why revert #337 Of course, it is also a method to address this issue, but its implementation logic is not very sound. It abandons the optimization of genericization and is unable to handle situations where the number of incoming values exceeds the number of tokens.