changed to use secure operations to restrict operations #25
Conversation
| await tableOperations.DeleteRecordAsync(record, cancellationToken); | ||
| SecureTableOperations<T> tableOperations = new(connection); | ||
| object primaryKey = tableOperations.BaseOperations.GetPrimaryKeys(record).First(); | ||
| await tableOperations.DeleteRecordWhereAsync(HttpContext.User, $"{PrimaryKeyField} = {{0}}", cancellationToken, primaryKey); |
There was a problem hiding this comment.
Why are we changing this call?
Shouldn't we use
await tableOperations.DeleteRecordAsync(HttpContext.User, record, cancellationToken);
| SecureTableOperations<T> tableOperations = new(connection); | ||
|
|
||
| T? result = tableOperations.NewRecord(); | ||
| T? result = tableOperations.BaseOperations.NewRecord(); |
There was a problem hiding this comment.
for cleaner operation let's add NewRecord to SecureTableOperations
| TableOperations<T> tableOperations = new(connection); | ||
| string tableName = tableOperations.TableName; | ||
| SecureTableOperations<T> tableOperations = new(connection); | ||
| string tableName = tableOperations.BaseOperations.TableName; |
There was a problem hiding this comment.
| string tableName = tableOperations.BaseOperations.TableName; | |
| string tableName = tableOperations.TableName; |
Let's handle this in SecureTableOperations There are ways to have optional parameters in an interface definition., That would allow SecureTableOeprationsto beITableOperations` which I think makes this cleaner
There was a problem hiding this comment.
I thought we were avoiding doing that since adding a ClaimsPrincipal would change basically every function footprint away from the ITableOperations interface.
In anycase, I'll put up a branch with the required change for indirection being taken care of by SecureTableOperations .
This PR implements claim checking as an additional security measure to filter data through a tableoperations wrapper in model controllers.
JIRA Ticket(s)
Additional Support for: DIG-21
Ticket: DIG-22
Required PRs