Describe the bug
The constructor for OrRequestMatcher fails with NullPointerException if the argument is a list created with Java's List.of method.
To Reproduce
new OrRequestMatcher(List.of(new AntPathRequestMatcher("/test")));
Expected behavior A working object is constructed
Sample
See steps to reproduce
Reports that include a sample will take priority over reports that do not. At times, we may require a sample, so it is good to try and include a sample up front.
Comment From: terminux
Hi, this is because the contains method of java.util.List is used in the constructor of OrRequestMatcher to verify whether requestMatchers contains null values.
https://github.com/spring-projects/spring-security/blob/4a976faea3a28dbaadc11109d03421b8385b0e13/web/src/main/java/org/springframework/security/web/util/matcher/OrRequestMatcher.java#L43
It works fine when requestMatchers is an instance of java.util.AbstractCollection (e.g. java.util.ArrayList), because the contains method parameter of java.util.AbstractCollection supports null values, its source code is like this:
public boolean contains(Object o) {
Iterator<E> it = iterator();
if (o == null) {
while (it.hasNext())
if (it.next() == null)
return true;
} else {
while (it.hasNext())
if (o.equals(it.next()))
return true;
}
return false;
}
However, the source code of the List.of method is like this:
static <E> List<E> of(E e1) {
return new ImmutableCollections.List12<>(e1);
}
The contains method of ImmutableCollections.List12 is extended from AbstractImmutableCollection, and its source code is as follows:
public boolean contains(Object o) {
return indexOf(o) >= 0;
}
ImmutableCollections.List12 overrides the indexOf method, and its source code is as follows:
public int indexOf(Object o) {
Objects.requireNonNull(o);
if (o.equals(e0)) {
return 0;
} else if (e1 != EMPTY && o.equals(e1)) {
return 1;
} else {
return -1;
}
}
Its parameter does not support null values!
I believe you can use ArrayList or Collections.singletonList to solve your problem and I submitted a PR to fix it. #10705
Comment From: sgraca
@terminux Thanks for the explanation. That's exactly the same reason that I was able to find out. I used different list implementation to workaround the issue.
Comment From: jzheaux
Thanks for the report, @sgraca. This is now addressed in aaaf7d35235bf19d8207e890830c1557dbc76a32 and has been backported.