spring-projects / spring-projects/spring-security
SEC-2842: RoleHierarchyVoter should first filter ConfigAttributes received
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 9.6k
- Forks
- 6.3k
- Avg merge
- 2d 11h
- Merged PRs (30d)
- 52
Description
Jordi Llach Fernandez (Migrated from SEC-2842) said:
If no ConfigAttributes are supported by the voter by letting RoleVoter.vote do its bussiness without prior filtering useless calls to extractAuthorities are done
I've just overriden RoleHierarchyVoter.vote, which really belongs to RoleVoter, as follows
@Override
public int vote(Authentication authentication, Object object, Collection<ConfigAttribute> attributes) {
List<ConfigAttribute> sup = attributes.stream().filter(a -> this.supports(a)).collect(Collectors.toList());
if (!sup.isEmpty()) return super.vote(authentication, object, sup);
else return ACCESS_ABSTAIN;
}
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by locating RoleHierarchyVoter.vote and the RoleVoter.vote path that calls extractAuthorities, then inspect how ConfigAttribute support is checked. The change is complete when unsupported attributes do not trigger authority extraction and the voter abstains when no supported attributes remain; add or update coverage for both outcomes.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- authorization, security
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100