Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Kotlin support to DefaultMethodSecurityExpressionHandler #15093

Closed
call-me-baki opened this issue May 18, 2024 · 0 comments
Closed

Add Kotlin support to DefaultMethodSecurityExpressionHandler #15093

call-me-baki opened this issue May 18, 2024 · 0 comments
Assignees
Labels
status: waiting-for-triage An issue we've not yet triaged type: enhancement A general enhancement
Milestone

Comments

@call-me-baki
Copy link
Contributor

call-me-baki commented May 18, 2024

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:

@call-me-baki call-me-baki added status: waiting-for-triage An issue we've not yet triaged type: enhancement A general enhancement labels May 18, 2024
jzheaux added a commit that referenced this issue May 31, 2024
@jzheaux jzheaux added this to the 6.4.0-M1 milestone May 31, 2024
@jzheaux jzheaux self-assigned this May 31, 2024
@call-me-baki call-me-baki changed the title Add Kotlin support in DefaultMethodSecurityExpressionHandler Add Kotlin support to DefaultMethodSecurityExpressionHandler Jun 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: waiting-for-triage An issue we've not yet triaged type: enhancement A general enhancement
Projects
Status: No status
Development

No branches or pull requests

2 participants