Bugfix - matching blacklisted_paths on request_target instead of uri.

[schroedingerskatze42]

Q	A
Bug fix?	yes
New feature?	no
BC breaks?	no
Deprecations?	no
Related tickets	-
Documentation	-
License	MIT

What's in this PR?

matched the wrong subject; need to match the path of a request, not the uri object

Why?

need to match the path of a request, not the uri object

[dbu]

what is wrong with using the whole uri? i expect it could make sense in some scenarios to also consider the domain in the blacklist, or not?

[dbu]

@nobYsDarling ping - i want to tag a release, but if we change the behaviour we should do it before tagging a release to avoid BC breaks.

[dbu]

ping @nobYsDarling why don't you want to match on the whole url?

[dbu]

hi @nobYsDarling i'd love to wrap this up. can you please tell why you don't want to match the domain?

[Nyholm]

The Uri object is converted to a string. So I think the current implementation is fine. @nobYsDarling could you tell me why we need this change?

[GrahamCampbell]

Maybe it was picked up by a static analyzer or IDE, since the old code could fail if strict types were enabled for the file.

[dbu]

unless i am mistaken, the significant difference here is that getUri gives you the host name as well, but request target is only the path without host name.

what if we (string) $request->getUri()?

[Nyholm]

I've reviewed this PR and also looked at the test.
I see that the intention was to only use paths and this PR corrects your original PR where you added that features.

However, I think it is better to include the full URL. That would make this feature even more powerful and flexible.

I'll close this PR, If I still misunderstand you, please reopen it or add a comment.