execLogin's return shape. Only cookies/headers are ever read by the host
(lanrurugi-api::plugins::with_login_cookies), which folds them into the next
metadata/download call's MetadataHostArgs.user_agent_cookies/
user_agent_headers — every other property a real legacyCompat.userAgent() instance exposes
is a function, which JSON.stringify silently drops crossing the dispatcher's
newline-delimited-JSON boundary (see dispatcher.ts's own LegacyUserAgent.cookies docs), so
returning the whole ua object works, but only these two plain-data fields survive.
cookies: LegacyCookie[]
headers: Record<string, string>
Any header/token-based credential this login plugin wants a downstream metadata/download
call to send (e.g. { "Authorization": "Key <api_key>" }, a bearer token, a custom
signed-request header — whatever the target site's own auth scheme needs). Independent of
cookies and of LegacyUserAgent entirely: a plugin using
legacyCompat.userAgent() can hand back its own ua.headers snapshot here (see that
property's own docs), but nothing requires going through userAgent() at all — a plugin that
authenticates with a plain fetch() call and holds the resulting token in a local variable
can just return { headers: { Authorization: Bearer ${token} } } directly. For a site
authenticating via a header/token rather than a cookie, this is the only way that credential
actually reaches a downstream call; cookies alone is empty for such a login plugin (issue
#78/#93: nhapiauth's Authorization header used to have no way to cross this boundary at
all before this field existed).
error: PluginError