Skip to content

Add Kotlin support to DefaultMethodSecurityExpressionHandler  #15093

@call-me-baki

Description

@call-me-baki

Expected Behavior
When using the @PreFilter and @PostFilter annotations with Kotlin's Collection and Map, the filtering logic should be applied as it is in Java code.

Current Behavior
Any Kotlin Collections and empty Maps throw an UnsupportedOperationException as these types in Kotlin are immutable, but the implementation of DefaultMethodSecurityExpressionHandler attempts to mutate their state.

Minimal reproducible example:

Context
For Collections, that happens in the following lines:

For Mapss, the same happens in the following lines:

This fact is also reflected in the javadoc:

* If a {@code Collection} or {@code Map} is used, the original instance will be
* modified to contain the elements for which the permission expression evaluates to
* {@code true}. For an array, a new array instance will be returned.

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:

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions