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 issue is the combination of a security manager and the fact jakarta authorization uses a policy. As soon as the policy itself needs any kind of Java SE permission, the security manager will ask the policy, which is itself. This then leads to recursion.
Ultimately the design of mixing Java SE code level permissions and permissions wrt the logged-in user are wrong. We'll address this in EE 11. For now we can install a proxy that doesn't send Java SE permissions to the Jakarta Authorisation Policy.
Note that the standalone TCK passes sinds a) it doesn't use the security manager, and b) uses wars, which seemly just happen to not ask for a certain class loading permission.
See https://gist.github.com/scottmarlow/67a2c64b88f8453a622931235c12ad4e
The issue is the combination of a security manager and the fact jakarta authorization uses a policy. As soon as the policy itself needs any kind of Java SE permission, the security manager will ask the policy, which is itself. This then leads to recursion.
Ultimately the design of mixing Java SE code level permissions and permissions wrt the logged-in user are wrong. We'll address this in EE 11. For now we can install a proxy that doesn't send Java SE permissions to the Jakarta Authorisation Policy.
Note that the standalone TCK passes sinds a) it doesn't use the security manager, and b) uses wars, which seemly just happen to not ask for a certain class loading permission.
CC @scottmarlow
The text was updated successfully, but these errors were encountered: