Skip to main content

CredentialStore

leviath_core::credentials

Trait CredentialStore 

Source 
pub trait CredentialStore: Send + Sync {
    // Required methods
    fn get(&self, account: &str) -> Result<Option<String>, String>;
    fn set(&self, account: &str, secret: &str) -> Result<(), String>;
    fn delete(&self, account: &str) -> Result<bool, String>;

    // Provided method
    fn read_all(&self, accounts: &[String]) -> BTreeMap<String, String> { ... }
}
Expand description

A place secrets can be put and taken back out.

A trait rather than a concrete type so the config and MCP-auth layers can be tested against an in-memory store without reaching the OS, and so a future backend (a remote secret manager, say) has somewhere to land.

Required Methods§

Source

fn get(&self, account: &str) -> Result<Option<String>, String>

The stored secret for account, or None if there is none.

A missing entry is Ok(None); an unreachable or locked store is Err. The distinction matters: collapsing a locked keychain into None would surface to the user as “no API key configured” and send them to re-run lev setup instead of unlocking their keychain.

Source

fn set(&self, account: &str, secret: &str) -> Result<(), String>

Store secret under account, replacing anything already there.

Source

fn delete(&self, account: &str) -> Result<bool, String>

Remove account, reporting whether anything was actually removed, so a caller can clean up unconditionally.

Provided Methods§

Source

fn read_all(&self, accounts: &[String]) -> BTreeMap<String, String>

Every one of accounts that is present, with its secret.

The OS stores offer no portable “list everything under this service” operation, so the caller supplies the accounts to look for - it knows them: the provider list is fixed and the MCP server list comes from the config.

An entry the store cannot return is skipped rather than aborting the whole read: one stale keychain item should not stop a user from running.

Dyn Compatibility§

This trait is dyn compatible.

In older versions of Rust, dyn compatibility was called "object safety".

Implementors§