Is your feature request related to a problem? Please describe.
See #1556.
Describe the solution you'd like
Following #1682, we should change the Rust implementation of the view service to use the new auth mechanism. This is also an opportunity to clean up the initialization flow.
Currently, we have code that initializes a view server with the user's full viewing key. Instead, we'll now use the auth mechanism as a registration / initialization step:
[ ] Add an implementation of the ViewAuthService RPC added in #1682:
[ ] Use the SQLite database to record a set of ViewAuthTokens (random 32 byte strings)
[ ] Handle ViewAuthRequest by checking if there is an FVK in SQLite:
if we have not set the FVK, set the FVK to the provided FVK, generate 32 random bytes, save those bytes as a ViewAuthToken, and return it to the client.
if we have set the FVK, check if the provided FVK is the existing one (erroring if not), then generate a new ViewAuthToken, save it, and return it to the client.
[ ] Change the startup logic for the view service so that the worker starts when the FVK is registered, and not before. Remove the existing logic that initializes the view service with an FVK (we'll use registration for that).
[ ] Change the view service implementation to check request authorization by checking whether the provided ViewAuthToken is a valid one.
[ ] Change pcli to register with its internal view service on startup. We'll need a way to save state in pcli beyond the view service data, so we can save the auth tokens. We don't currently have any state other than the view service and the custody service, but we'll need it to be able to record viewing keys if we have custody mechanisms that don't allow access to the spending key.
Because of the last point, it's probably worth waiting to make this change until after we have a more flexible custody story for pcli.
Is your feature request related to a problem? Please describe.
See #1556.
Describe the solution you'd like
Following #1682, we should change the Rust implementation of the view service to use the new auth mechanism. This is also an opportunity to clean up the initialization flow.
Currently, we have code that initializes a view server with the user's full viewing key. Instead, we'll now use the auth mechanism as a registration / initialization step:
ViewAuthService
RPC added in #1682:ViewAuthToken
s (random 32 byte strings)ViewAuthRequest
by checking if there is an FVK in SQLite:ViewAuthToken
, and return it to the client.ViewAuthToken
, save it, and return it to the client.ViewAuthToken
is a valid one.pcli
to register with its internal view service on startup. We'll need a way to save state inpcli
beyond the view service data, so we can save the auth tokens. We don't currently have any state other than the view service and the custody service, but we'll need it to be able to record viewing keys if we have custody mechanisms that don't allow access to the spending key.Because of the last point, it's probably worth waiting to make this change until after we have a more flexible custody story for
pcli
.