Hi,
I’m confused about the behavior. I have these two statements:
var result = await persistentSubscriptionClient.ReadStreamAsync(Direction.Forwards, "FavouriteFilter-517ce734-3c2b-482b-a229-f83fc8bdb4d6", StreamPosition.Start).ToListAsync();
var result1 = await persistentSubscriptionClient.ReadAllAsync(Direction.Forwards, Position.Start).ToListAsync();
private static EventStoreClient CreateSubscriptionClient()
{
return new EventStoreClient(EventStoreClientSettings.Create("esdb:// IP ?Tls=true&TlsVerifyCert=false"));
}
The first line works as expected. The second line (ReadAllAsync) throws an exception. =>
EventStore.Client.AccessDeniedException: ‘Status(StatusCode=“PermissionDenied”, Detail=“Access Denied”)’
Why is that? All I want is to read all events and write to another EventStore…
Thanks
Dani
the $all stream requires admin access.
Sorry for the late reply, but I wanted to add my two cents.
The reason for reads (and subscriptions, which are reads anyway) from $all to require admin access is that all the reads from $all are bypassing normal permissions checks like ACLs. The $all pseudo-stream is a representation of the physical log on disk, and reads from it are optimised for performance. Checking things like ACLs when reading from the log would require to keep a lot of metadata objects for many streams in memory, or access them on disk (as they are part of the log as stream metadata events).
When you are reading from a regular stream, it would just check your access to that stream once. If you are reading from a stream of links, each action to resolve the linked event would go through the normal permissions check, so it could be slower (unless you’re an admin).
In theory, nothing fundamentally prevents us to do the same for $all, and we had some discussions about it. It’s just people are used to very fast reads from $all, so one option we discussed is to keep a shortcut for admin users. I personally think it makes sense.
At the same time, we are avoiding doing big changes that involve ACL because we are considering to implement something else instead. There will be something in that space next year for sure.