Securing the sharding data

A developer created a multi-tenant application that uses sharding and, by mistake he deleted the FileStore Cache file (see issue #115 how that happens). At that point he lost the sharding information and he couldn't get it back. While the deletion of a FileStore Cache file is very rare, the consequences of loosing the sharding information on an active application would be very bad. Therefore I added code in AuthP version 8.1.0 a new feature to backup the sharding information, plus some features to ensure the sharding information is correct. This page shows what you need to do to use this new feature.

NOTE: You may ask why I use the FileStore Cache if it has this problem?. Its all about performance. Every access to the tenant's data needs the specific sharding data for that tenant, and typically more that 90% of all the requests needs the sharding data. In terms of speed the FileStore Cache get the sharding in ~25 ns, while using a SQL Server distributed cache would take at least 0.1 ms – that means FileStore cache is >4,000 faster.

Overview of the "Secure your sharding data" feature.

The solution in AuthP version 8.1.0 adds a new database called ShardingEntryBackup (referred to as 'ShardingBackup database') to the AuthP's AuthPermissionsDbContext and extra code is added to the GetSetShardingEntriesFileStoreCache so any change to a sharding information in the the FileStore Cache will also update the database ShardingEntryBackup.

For new multi-tenant applications built with AuthP version 8.1.0 the backup is automatic, but if you are updating an existing multi-tenant application, then you need to run the method called CheckTwoShardingSources in the GetSetShardingEntriesFileStoreCache which will copy the existing FileStore Cache's sharding data to the ShardingEntryBackup. See the next section for how you do this.

What the CheckTwoShardingSources method does