Vulnerability in EPiServer.Forms
I am using Episerver Find to generate a list of pages where a property matches a specific value. This is not a problem and I get a correct search result.
However, to respect page access rights, I also tried adding the FilterOnReadAccess method to the filter chain. Then I get no results from the search, even though the pages have virtual roles like Everyone and Anonymous added with at least Read access checked. I have verified these roles in both CMS and Find shells, so they should be indexed alright.
I am using these versions of relevant NuGet packages:
Anything I should consider changing for the search? Any help will be appreciated.
Have you verified that the actual indexed documents has the correct role(s) in the RolesWithReadAccess field? Or is that what you meant with "I have verified these roles in both CMS and Find shells, so they should be indexed alright."
And also verified that the user (Principal) is indeed in one of those roles when performing the search?
Just found and fixed this issue.
It all worked fine for a logged-in user. But it turns out that the name property of an anonymous ClaimsIdentity is null when in a WebAPI and SuppressDefaultHostAuthentication is enabled. Episerver, on the other hand, expects that name to at least be an empty string. So even though the anonymous user had some of the virtual roles with read access, and should therefore be able to see the pages, Episerver would ignore those virtual roles for that filter.
Thanks for posting the solution
It is not Episerver doing however. Aspnetidentity by default expect a cookie for logged in users, and SuppressDefaultHostAuthentication removes that cookie for Web api controllers, rendering all requests to be anonymonus
Using SuppressDefaultHostAuthentication together with a sorted list of passive host authentication filters (including the cookie middleware), so requests are not always anonymous. 😉
The issue was that SuppressDefaultHostAuthentication makes an unauthenticated request fall back to an identity with null name, but falling back to FallbackPrincipal.AnonymousPrincipal works.
But actually, even if Name is null, it would be nice if FilterOnReadAccess would recognize Anonymous and Everyone roles, as long as IsAuthenticated is false.