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 the Znap.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 Shuttle's runtime doesn't have such path available, the keypair should be stored somewhere else and should be accessible within the run-time serving the API.
This issue is related to #83
And we should follow a similar strategy and set up the secrets in Shuttle.
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 Shuttle's runtime doesn't have such path available, the keypair should be stored somewhere else and should be accessible within the run-time serving the API.
This issue is related to #83
And we should follow a similar strategy and set up the secrets in Shuttle.