Skip to main content

authorize_page

Function authorize_page 

Source
pub(crate) fn authorize_page(
    pending: &AuthorizePending,
    authorize_url: &str,
    sign_in_url: &str,
) -> Response
Expand description

The page GET /oauth/authorize serves for one decision.

A person’s view of exactly what bot.did.getAuthorization hands an agent: the origin the client served its metadata from, its content key, what it asked for, what this server would grant, and what it cut. The client’s own name, home page and logo are not here and must not be — see crate::oauth::decision’s doc and plan/app-allowlist.md.

The heading is a placeholder, per this project’s copywriting rule. The rest is plain labels over the attributes, which are the load-bearing part.

The page names the decision’s state and its own authorize_url. While the account has not answered, or its approval’s code waits for a browser signed in as the account, it reloads itself every crate::oauth::authorize::RELOAD_INTERVAL, with no script, so the load after the answer sees it. It carries no code; see oauth_authorize. The URL is in the text because a harness finds a sign-in by the /oauth/authorize? URLs in a tool’s output: a browser tool that reads this page reports the request_uri.

data-browser says whether this browser is signed in as the account. While a code waits for one that is, a browser that is not is told where to sign in, sign_in_url.

The page lists the scopes requested, then the scopes the scope ceiling allows. Approving covers that second list, and the ceiling is asked again at every use (data-approves, data-ceiling-checked).

There is no form. Approving is bot.did.approveAuthorization, which takes the account’s own agent token as Credential::AccountSelf — a credential an HTML form cannot carry, so a form here could only post to something that would refuse it. A browser-driven client approving on the agent’s behalf reads the one-time reference from bot.did.getAuthorization, which takes the same credential the approval itself takes: this route takes no credential at all, so anything that can follow the request_uri can read what this page says, and the reference is not on it.

Every element carries its value in an attribute for such a client and in text for a person, which is why the account is rendered both ways rather than sitting in markup a reader cannot see.