Closed danmt closed 1 month ago
Generally the best way to handle this is by means of secrets since in the building, CI and Runtime processes they are kept hidden, in the same way in infrastructures that use docker the secrets are used, these at code level work the same as the environment variables so I think we should opt for something more like this:
let identity_keypair =
Keypair::read_from_file(env::var("IDENTITY_KEYPAIR_PATH").unwrap())
.or(Keypair::from_bytes(env::var("IDENTITY_KEYPAIR").unwrap_or_default().as_bytes()))
.unwrap();
related #84
Action Identities let Action Providers have verifiable on-chain transactions. The mechanics behind it are pretty simple, we have a secret key used to sign a unique message attached to each transaction returned by the API, this is then used to verify the authentication of an Action.
The way this works atm involves an
identity
property in theZnap.toml
file pointing to the same path where Solana stores the default Keypair in your OS~/.config/solana/id.json
. This works fine locally as long as you have such file and you can serve the API in your server and by having a keypair that path you can assure it all works well.The problem comes when we try to serve the API in a run-time outside our direct control. For example, the Github Actions runtime doesn't have such path available, the keypair should be store somewhere else and should be accessible within the run-time serving the API.
There are multiple ways to solve this, we want to avoid changing Znap API as much as possible. Being able to configure this in the Znap.toml without changing the logic of the framework would be a great solution. For Github runtime, we need a way to "upload" or "set up" a keypair.
Something like this in the
Znap.toml
might work: