Change in source filter causes empty list to be returned

[elsand]

Description of the bug

It appears a change to the source filter which shouldn't have any effect causes events to be excluded from the resulting list. I suspect this has to do with the initial limited query to the database no longer includes the actual event.

Steps To Reproduce

1. Request https://platform.tt02.altinn.no/events/api/v1/events?after=41837b80-ad20-465f-adab-0e9a690a402b&source=https://dialogporten.no/api/v1/dialogs/%, authenticate as org=digdir
2. Note that the first returned entry has "source": "https://dialogporten.no/api/v1/dialogs/1e038d0f-7738-4a51-b9f8-b44b2fca94ee"
3. Add 1 to the source filter, ie request https://platform.tt02.altinn.no/events/api/v1/events?after=41837b80-ad20-465f-adab-0e9a690a402b&source=https://dialogporten.no/api/v1/dialogs/1%

Expected results: The same entry should be the first in the list returned
Actual results: Empty list

Additional Information

This might have to do with the fact that the implicit limit of 50(?) elements is used directly in the query along with any other predicates, such as source filter. This causes a different set of items to be returned, which may or may not include the events the user is authorized to see.

[SandGrainOne]

@elsand We now have a change in AT where this endpoint will be expecting resource instead of source. Will this cause any issues for you?

[elsand]

This will likely solve the issue for most cases, but the underlying problem outlined under "additional information" above will still apply until we figure a way to ensure that the limited amount of elements fetched from the database are pre-authorized.

For example, assume a resource X with a policy rule that states that a user are authorized to read events with resource: X and type: Y. There's 100 cloudevents in the database with resource: X, the first 50 have type: Z and the last 50 have type: Y. A request to ?resource=X&after=0&size=50 will thus fetch the first 50, which the user is not authorized to read. This will result in a empty array in response, and no way for the user to fetch the events they are authorized to read (the last 50).

We discussed this issue in the authZ workshop. My take is that events will have to implement something akin to what's described in Altinn/dialogporten#42 in order to properly have full authorization support, not to mention it being able to scale performance-wise.

[olebhansen]

@SandGrainOne : Investigate if it is possible (i.e. we have the right inputs) to do pre-authorization