Struct ProfileSummary 

pub struct ProfileSummary {
    pub name: String,
    pub base_url: String,
    pub challenge_bypass: bool,
    pub eab_enabled: bool,
}

One ACME endpoint, as every surface describes it.

The two front ends reach this from opposite directions, and the difference is real rather than an implementation detail. GET /api/profiles and /ui/profiles build it from a mounted acme_proxy_protocol::profile::Profile, so they describe what this process is actually serving; acme-proxy profile list builds it from the configuration, because the alternative is server::profile::build_all, which constructs signer backends – generating a CA key and contacting a relay upstream for a read-only listing. That is filter show’s split exactly: the panel serves the live thing, the terminal rebuilds one, and between an edit and its SIGHUP the two legitimately disagree.

Fields

name: String

base_url: String

challenge_bypass: bool

eab_enabled: bool

Implementations

impl ProfileSummary

pub fn mounted(profile: &Profile) -> Self

An endpoint this process is serving.

pub fn configured(base_url: &str, profile: &ProfileConfig) -> Self

An endpoint this configuration would mount.

Config::resolve_profiles has already dropped anything enabled = false on the caller’s behalf, so this needs no filter of its own – the list it is mapped over is already the mounted set, minus the fact of being mounted.

pub fn directory_url(&self) -> String

Where a client fetches this endpoint’s directory (RFC 8555 §7.1.1).