Add Kotlin support to DefaultMethodSecurityExpressionHandler
#15093
Labels
Milestone
DefaultMethodSecurityExpressionHandler
#15093
Uh oh!
There was an error while loading. Please reload this page.
Expected Behavior
When using the
@PreFilter
and@PostFilter
annotations with Kotlin'sCollection
andMap
, the filtering logic should be applied as it is in Java code.Current Behavior
Any Kotlin
Collection
s and emptyMap
s throw anUnsupportedOperationException
as these types in Kotlin are immutable, but the implementation ofDefaultMethodSecurityExpressionHandler
attempts to mutate their state.Minimal reproducible example:
Context
For
Collection
s, that happens in the following lines:spring-security/core/src/main/java/org/springframework/security/access/expression/method/DefaultMethodSecurityExpressionHandler.java
Lines 154 to 155 in 64e2a2f
For
Maps
s, the same happens in the following lines:spring-security/core/src/main/java/org/springframework/security/access/expression/method/DefaultMethodSecurityExpressionHandler.java
Lines 192 to 193 in 64e2a2f
This fact is also reflected in the
javadoc
:spring-security/core/src/main/java/org/springframework/security/access/expression/method/DefaultMethodSecurityExpressionHandler.java
Lines 115 to 117 in 64e2a2f
Moreover, the official Spring Security documentation on Method Security, specifically the sections Filtering Method Parameters with
@PreFilter
and Filtering Method Results with@PostFilter
clearly mention that "@PreFilter
/@PostFilter
is not yet supported for Kotlin-specific data types; for that reason, only Java snippets are shown".How has this issue affected you?
It has prevented me from being able to use the
@PreFilter
and@PostFilter
annotations in my Spring Boot projects written in Kotlin.What other alternatives have you considered?
Writing my own implementation of the
MethodSecurityExpressionHandler
interface.This works for my usecase, but I would like the whole Spring Security community to benefit and be able to use the
@PreFilter
/@PostFilter
with Kotlin by default. Additionally, implementing this solution within my own codebase increases internal dependencies and liabilities.What are you trying to accomplish?
Add first-party support for the Kotlin data types by making
DefaultMethodSecurityExpressionHandler
work with them.Are you aware of any workarounds?
Using the mutable variants of Kotlin's read-only data types.
This does not work for my usecase as it undermines the benefits of Kotlin's (preferred) in-built immutable types.
Action Items
Proposed solution in the following pull request:
The text was updated successfully, but these errors were encountered: