[ 
https://issues.apache.org/jira/browse/SYNCOPE-2010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Francesco Chicchiriccò updated SYNCOPE-2010:
--------------------------------------------
    Description: 
h4. Problem

{{DefaultPasswordGenerator.merge(List<DefaultPasswordRuleConf>)}} always 
returns a configuration with \{{usernameAllowed == true}}, even when every 
input configuration has {{{}usernameAllowed == false{}}}.
h4. How to reproduce

The test added in this PR fails on current {{master}} without the fix:
{code:java}
@Test
void allForbid() {
    List<DefaultPasswordRuleConf> rules = new ArrayList();
    rules.add(configRule(false));
    rules.add(configRule(false));
    assertFalse(passwordGenerator.merge(rules).isUsernameAllowed());
}
{code}
h4. Cause

In {{{}merge{}}}, {{result}} is initialized with 
{{result.setUsernameAllowed(true)}}
and is never set to {{false}} before the following check
[https://github.com/apache/syncope/blob/193c94e019034071f13de4875d006377a3c5dac0/core/spring/src/main/java/org/apache/syncope/core/spring/security/DefaultPasswordGenerator.java#L153-L155]
{code:java}
if (!result.isUsernameAllowed()) {
    result.setUsernameAllowed(ruleConf.isUsernameAllowed());
}
{code}
The condition can therefore never be true, and the value of {{usernameAllowed}} 
in the input configurations is never read.

  was:
h4. Problem

{{DefaultPasswordGenerator.merge(List<DefaultPasswordRuleConf>)}} always returns
a configuration with\{{usernameAllowed == true}}, even when every input 
configuration has {{{}usernameAllowed == false{}}}.
h4. How to reproduce

The test added in this PR fails on current {{master}} without the fix:
{code:java}
@Test
void allForbid() {
    List<DefaultPasswordRuleConf> rules = new ArrayList();
    rules.add(configRule(false));
    rules.add(configRule(false));
    assertFalse(passwordGenerator.merge(rules).isUsernameAllowed());
}
{code}
h4. Cause

In {{{}merge{}}}, {{result}} is initialized with 
{{result.setUsernameAllowed(true)}}
and is never set to {{false}} before the following check
[https://github.com/apache/syncope/blob/193c94e019034071f13de4875d006377a3c5dac0/core/spring/src/main/java/org/apache/syncope/core/spring/security/DefaultPasswordGenerator.java#L153-L155]
{code:java}
if (!result.isUsernameAllowed()) {
    result.setUsernameAllowed(ruleConf.isUsernameAllowed());
}
{code}
The condition can therefore never be true, and the value of {{usernameAllowed}} 
in the input configurations is never read.


> DefaultPasswordGenerator#merge ignores usernameAllowed
> ------------------------------------------------------
>
>                 Key: SYNCOPE-2010
>                 URL: https://issues.apache.org/jira/browse/SYNCOPE-2010
>             Project: Syncope
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 3.0.16, 4.0.9, 4.1.4
>            Reporter: Francesco Chicchiriccò
>            Assignee: Francesco Chicchiriccò
>            Priority: Major
>             Fix For: 4.1.5, 4.2.0, 5.0.0
>
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> h4. Problem
> {{DefaultPasswordGenerator.merge(List<DefaultPasswordRuleConf>)}} always 
> returns a configuration with \{{usernameAllowed == true}}, even when every 
> input configuration has {{{}usernameAllowed == false{}}}.
> h4. How to reproduce
> The test added in this PR fails on current {{master}} without the fix:
> {code:java}
> @Test
> void allForbid() {
>     List<DefaultPasswordRuleConf> rules = new ArrayList();
>     rules.add(configRule(false));
>     rules.add(configRule(false));
>     assertFalse(passwordGenerator.merge(rules).isUsernameAllowed());
> }
> {code}
> h4. Cause
> In {{{}merge{}}}, {{result}} is initialized with 
> {{result.setUsernameAllowed(true)}}
> and is never set to {{false}} before the following check
> [https://github.com/apache/syncope/blob/193c94e019034071f13de4875d006377a3c5dac0/core/spring/src/main/java/org/apache/syncope/core/spring/security/DefaultPasswordGenerator.java#L153-L155]
> {code:java}
> if (!result.isUsernameAllowed()) {
>     result.setUsernameAllowed(ruleConf.isUsernameAllowed());
> }
> {code}
> The condition can therefore never be true, and the value of 
> {{usernameAllowed}} in the input configurations is never read.



--
This message was sent by Atlassian Jira
(v10.3.26#10030026)

Reply via email to