You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The project I'm working on stores groovy code in one of the policy fields and some of the policies happen to use || operator.
Recent versions of jcasbin after loading policies end up with the operator replaced with a comma - this modification breaks the function we have in place which expects to evaluate the value of the field a groovy code and reports Script.groovy: 1: Unexpected input: ',' @ line 1...
The bug was introduced by PR #408 which was an attempt to fix issue #407. The real cause of issue #407, however, was in casbin/jdbc-adapter which didn't escape policy field values read in from the database before parsing the data as a CSV line - this was fixed by PR #74 which ended up in publicly available release of jdbc-adapter version 2.10.0.
Issue #407 does not require changes introduced by PR #408 and as those changes bring in a separate bug (at least in some cases), I'd like to ask for PR #408 be reverted and a new version be released.
The text was updated successfully, but these errors were encountered:
The project I'm working on stores groovy code in one of the policy fields and some of the policies happen to use
||
operator.Recent versions of
jcasbin
after loading policies end up with the operator replaced with a comma - this modification breaks the function we have in place which expects to evaluate the value of the field a groovy code and reportsScript.groovy: 1: Unexpected input: ',' @ line 1...
The bug was introduced by PR #408 which was an attempt to fix issue #407. The real cause of
issue #407
, however, was incasbin/jdbc-adapter
which didn't escape policy field values read in from the database before parsing the data as a CSV line - this was fixed by PR #74 which ended up in publicly available release ofjdbc-adapter
version2.10.0
.Issue #407
does not require changes introduced byPR #408
and as those changes bring in a separate bug (at least in some cases), I'd like to ask forPR #408
be reverted and a new version be released.The text was updated successfully, but these errors were encountered: