@vellumai/credential-executor 0.11.4-staging.3 → 0.11.4
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -11,6 +11,12 @@
|
|
|
11
11
|
* (`gateway/src/http/routes/remote-web-pairing-verification.ts`)
|
|
12
12
|
* - `POST /v1/remote-web/pairing-token` poll + exchange device code
|
|
13
13
|
* (`gateway/src/http/routes/remote-web-pairing-token.ts`)
|
|
14
|
+
* - `GET /v1/remote-web/pairing-requests` list pending challenges
|
|
15
|
+
* (loopback-only)
|
|
16
|
+
* - `POST /v1/remote-web/pairing-requests/approve` approve by request id
|
|
17
|
+
* (loopback-only)
|
|
18
|
+
* - `POST /v1/remote-web/pairing-requests/deny` deny (delete) by request id
|
|
19
|
+
* (loopback-only)
|
|
14
20
|
*
|
|
15
21
|
* These shapes mirror those handlers' request/response bodies exactly so the
|
|
16
22
|
* gateway, the `vellum pair` CLI (`cli/src/commands/pair.ts`), and the web SPA
|
|
@@ -68,6 +74,60 @@ export interface RemoteWebPairingVerificationResponse {
|
|
|
68
74
|
expiresAt: string;
|
|
69
75
|
}
|
|
70
76
|
|
|
77
|
+
/**
|
|
78
|
+
* One pending challenge as shown on a host approval surface.
|
|
79
|
+
*
|
|
80
|
+
* The requesting device already sees the plaintext `userCode` in its own
|
|
81
|
+
* challenge response ({@link RemoteWebPairingChallengeResponse.userCode});
|
|
82
|
+
* the loopback-gated list route is the only host-side re-exposure. Displaying
|
|
83
|
+
* it there is what lets the approver match the code against the requesting
|
|
84
|
+
* device's screen: the device-flow anti-phishing binding.
|
|
85
|
+
*/
|
|
86
|
+
export interface RemoteWebPairingRequestSummary {
|
|
87
|
+
/** Opaque server-side id used to approve or deny this request. */
|
|
88
|
+
requestId: string;
|
|
89
|
+
/** The human-readable code the requesting device is displaying (e.g. "ABCD-EFGH"). */
|
|
90
|
+
userCode: string;
|
|
91
|
+
/** Public base URL the challenge was minted for. */
|
|
92
|
+
publicBaseUrl: string;
|
|
93
|
+
/** ISO-8601 instant the challenge was minted. */
|
|
94
|
+
requestedAt: string;
|
|
95
|
+
/** ISO-8601 instant the challenge expires. */
|
|
96
|
+
expiresAt: string;
|
|
97
|
+
/**
|
|
98
|
+
* Client IP of the mint request: the loopback/host address when minted
|
|
99
|
+
* locally, or the edge-observed client address when the mint arrived
|
|
100
|
+
* through the nginx tunnel edge (which stamps it via `proxy_set_header`,
|
|
101
|
+
* so a remote client cannot smuggle a value).
|
|
102
|
+
*/
|
|
103
|
+
requesterIp: string;
|
|
104
|
+
/** User-Agent header of the mint request, or null when absent. */
|
|
105
|
+
requesterUserAgent: string | null;
|
|
106
|
+
/**
|
|
107
|
+
* Whether the mint arrived through the public tunnel edge rather than the
|
|
108
|
+
* host itself.
|
|
109
|
+
*/
|
|
110
|
+
viaEdgeProxy: boolean;
|
|
111
|
+
}
|
|
112
|
+
|
|
113
|
+
/** `GET /v1/remote-web/pairing-requests` success response body (200). */
|
|
114
|
+
export interface RemoteWebPairingRequestListResponse {
|
|
115
|
+
requests: RemoteWebPairingRequestSummary[];
|
|
116
|
+
}
|
|
117
|
+
|
|
118
|
+
/**
|
|
119
|
+
* Request body for the pairing-request approve and deny routes. The approve
|
|
120
|
+
* route's success body reuses {@link RemoteWebPairingVerificationResponse}.
|
|
121
|
+
*/
|
|
122
|
+
export interface RemoteWebPairingRequestActionRequest {
|
|
123
|
+
requestId: string;
|
|
124
|
+
}
|
|
125
|
+
|
|
126
|
+
/** `POST /v1/remote-web/pairing-requests/deny` success response body (200). */
|
|
127
|
+
export interface RemoteWebPairingRequestDenyResponse {
|
|
128
|
+
status: "denied";
|
|
129
|
+
}
|
|
130
|
+
|
|
71
131
|
/** `POST /v1/remote-web/pairing-token` request body. */
|
|
72
132
|
export interface RemoteWebPairingTokenRequest {
|
|
73
133
|
/** The `deviceCode` from the challenge. */
|