mirror of
https://github.com/digital-asset/daml.git
synced 2024-09-20 01:07:18 +03:00
33c7a1aace
* Implementation for the configuration management service - Add configuration generation to the response of SetTimeModel - Implement the ConfigManagementService - Implement integration test into test tool This is still a draft as it has unsolved FIXMEs and it conflicts with #3744 which should go first. The main conflict is with changes to PartyAllocationResponse which cannot no longer reference "domain.PartyDetail" as we would have a cyclic dependency (participant-state contains Configuration which we point to from domain.ConfigurationEntry). The still open issues are: - Revisit PartyDetail - Naming: LedgerConfigurationService and ConfigManagementService are not talking about the same configuration and it feels confusing. - Remove duplication of ConfigurationEntry? Do we need both domain.ConfigurationEntry and ledger.store.ConfigurationEntry? Only difference is in the types of participantId and submissionId. * Address review part 1 * Fix up tests after rebase and address PR review * Post-merge fixes * Add missing config MRT checks and fixes to tests - Check config MRT in InMemoryLedger and SqlLedger - Use proper source of time in ConfigManagement - Separate out ConfigManagementServiceIT in sandbox conformance tsets * Reformat |
||
|---|---|---|
| .. | ||
| src | ||
| BUILD.bazel | ||
| README.md | ||
Ledger API authorization
General authorization in gRPC
An Interceptor reads HTTP headers, and stores relevant information (e.g., claims) in a Context.
GRPC services read the stored data from the Context in order to validate the requests.
Authorization in the ledger API
The AuthService defines an interface for decoding HTTP headers into Claims.
The ledger API server takes an AuthService implementation as an argument.
The ledger API server uses a call interceptor and the given AuthService implementation to to store decoded Claims in the gRPC Context.
All ledger API services use the Claims to validate their requests.