← All changes
|
jetpack_vendor/automattic/jetpack-backup/src/rest/class-restore-bridge.php
+372
-0
16.2-beta
→
16.3
View file →
| @@ -1,0 +1,372 @@ | ||
| 1 | +<?php | |
| 2 | +/** | |
| 3 | + * Restore REST bridge — proxies wpcom/v2 /sites/{site}/rewind/restores. | |
| 4 | + * | |
| 5 | + * @package automattic/jetpack-backup-plugin | |
| 6 | + */ | |
| 7 | + | |
| 8 | +namespace Automattic\Jetpack\Backup\V0005\REST; | |
| 9 | + | |
| 10 | +use Automattic\Jetpack\Connection\Client; | |
| 11 | +use WP_Error; | |
| 12 | +use WP_REST_Request; | |
| 13 | +use WP_REST_Server; | |
| 14 | + | |
| 15 | +if ( ! defined( 'ABSPATH' ) ) { | |
| 16 | + exit( 0 ); | |
| 17 | +} | |
| 18 | + | |
| 19 | +/** | |
| 20 | + * Restore endpoints powering the Restore screen: | |
| 21 | + * - POST /jetpack/v4/rewind/to/{rewindId} → initiate restore | |
| 22 | + * - GET /jetpack/v4/rewind/restore/{restoreId}/status → poll status | |
| 23 | + */ | |
| 24 | +class Restore_Bridge { | |
| 25 | + | |
| 26 | + /** | |
| 27 | + * Register routes. | |
| 28 | + * | |
| 29 | + * @return void | |
| 30 | + */ | |
| 31 | + public static function register_routes() { | |
| 32 | + register_rest_route( | |
| 33 | + 'jetpack/v4', | |
| 34 | + '/rewind/to/(?P<rewind_id>[A-Za-z0-9.\-]+)', | |
| 35 | + array( | |
| 36 | + 'methods' => WP_REST_Server::CREATABLE, | |
| 37 | + 'callback' => array( __CLASS__, 'initiate_restore' ), | |
| 38 | + 'permission_callback' => array( Rest_Controller::class, 'permission_check' ), | |
| 39 | + 'args' => array( | |
| 40 | + 'rewind_id' => array( | |
| 41 | + 'type' => 'string', | |
| 42 | + 'required' => true, | |
| 43 | + ), | |
| 44 | + 'types' => array( | |
| 45 | + 'type' => 'object', | |
| 46 | + // See the download bridge: `object` alone accepts a | |
| 47 | + // JSON list, because WordPress validates it with | |
| 48 | + // `is_array()`. | |
| 49 | + 'additionalProperties' => array( 'type' => 'boolean' ), | |
| 50 | + ), | |
| 51 | + ), | |
| 52 | + ) | |
| 53 | + ); | |
| 54 | + | |
| 55 | + register_rest_route( | |
| 56 | + 'jetpack/v4', | |
| 57 | + '/rewind/restore/(?P<restore_id>\d+)/status', | |
| 58 | + array( | |
| 59 | + 'methods' => WP_REST_Server::READABLE, | |
| 60 | + 'callback' => array( __CLASS__, 'get_restore_status' ), | |
| 61 | + 'permission_callback' => array( Rest_Controller::class, 'permission_check' ), | |
| 62 | + 'args' => array( | |
| 63 | + 'restore_id' => array( | |
| 64 | + 'type' => 'integer', | |
| 65 | + 'required' => true, | |
| 66 | + ), | |
| 67 | + ), | |
| 68 | + ) | |
| 69 | + ); | |
| 70 | + } | |
| 71 | + | |
| 72 | + /** | |
| 73 | + * Initiate a restore. | |
| 74 | + * | |
| 75 | + * Proxies POST wpcom/v2 /sites/{blog_id}/rewind/restores. | |
| 76 | + * | |
| 77 | + * This route exists because the v1 activity-log endpoint this used to | |
| 78 | + * call could never work from wp-admin: the v1 JSON API discards | |
| 79 | + * Jetpack user tokens by design, so `can_rewind()` evaluated an empty | |
| 80 | + * user and every request came back 401. The permission rule is the | |
| 81 | + * same on both — v1 simply had nobody logged in. | |
| 82 | + * | |
| 83 | + * Signed as the user, and that is not incidental: the guard upstream | |
| 84 | + * is `can_rewind()`, which needs `upload_files` and `delete_users` | |
| 85 | + * for a specific user id, so a bare blog token has no capabilities to | |
| 86 | + * evaluate and is rejected. It is also the right answer on its own | |
| 87 | + * terms — a restore is destructive and the activity log names the | |
| 88 | + * person who started it. | |
| 89 | + * | |
| 90 | + * @param WP_REST_Request $request The REST request. | |
| 91 | + * @return \WP_REST_Response|WP_Error | |
| 92 | + */ | |
| 93 | + public static function initiate_restore( WP_REST_Request $request ) { | |
| 94 | + $blog_id = Rest_Controller::get_blog_id_or_error(); | |
| 95 | + if ( is_wp_error( $blog_id ) ) { | |
| 96 | + return $blog_id; | |
| 97 | + } | |
| 98 | + $rewind_id = (string) $request->get_param( 'rewind_id' ); | |
| 99 | + $types = $request->get_param( 'types' ); | |
| 100 | + | |
| 101 | + // A supplied `types` that names nothing is refused rather than | |
| 102 | + // dropped, and this is the screen where that matters most: an | |
| 103 | + // absent `types` means every category upstream, so forwarding an | |
| 104 | + // empty selection as an omission would overwrite the live site | |
| 105 | + // with exactly the parts the caller excluded. | |
| 106 | + // | |
| 107 | + // The v2 route this now calls rejects it too, so there are two | |
| 108 | + // lines of defence — but this is the one that matters, since the | |
| 109 | + // other only fires after the request has left the site. | |
| 110 | + if ( Rest_Controller::request_names_no_types( $request ) ) { | |
| 111 | + return new WP_Error( | |
| 112 | + 'no_types_selected', | |
| 113 | + __( 'Select at least one item to restore.', 'jetpack-backup-pkg' ), | |
| 114 | + array( 'status' => 400 ) | |
| 115 | + ); | |
| 116 | + } | |
| 117 | + | |
| 118 | + // The rewind id travels in the body, in full. The decimal suffix is | |
| 119 | + // significant — it is passed straight to VaultPress as the backup's | |
| 120 | + // timestamp, and truncating it addresses a different backup than | |
| 121 | + // the reader picked. (`toIntRewindId` belongs to the file-browser | |
| 122 | + // URL family only, whose route regex really is `\d+`.) | |
| 123 | + $request_body = array( | |
| 124 | + 'rewindId' => $rewind_id, | |
| 125 | + // Optional upstream, and it now defaults to false — but both | |
| 126 | + // this dashboard and Calypso have always sent true, so omitting | |
| 127 | + // it would be a silent behaviour change for existing callers. | |
| 128 | + 'force_rewind' => true, | |
| 129 | + ); | |
| 130 | + | |
| 131 | + // Absent when the caller named no categories at all, which is how | |
| 132 | + // a whole-site restore is spelled upstream. Rebuilt as a named map | |
| 133 | + // otherwise — the same contract the download bridge follows. | |
| 134 | + $named_types = Rest_Controller::named_types( $types ); | |
| 135 | + if ( ! empty( $named_types ) ) { | |
| 136 | + $request_body['types'] = $named_types; | |
| 137 | + } | |
| 138 | + | |
| 139 | + $response = Client::wpcom_json_api_request_as_user( | |
| 140 | + sprintf( '/sites/%d/rewind/restores', $blog_id ), | |
| 141 | + 'v2', | |
| 142 | + array( 'method' => 'POST' ), | |
| 143 | + $request_body, | |
| 144 | + 'wpcom' | |
| 145 | + ); | |
| 146 | + | |
| 147 | + if ( is_wp_error( $response ) ) { | |
| 148 | + return Rest_Controller::transport_error( $response, 'restore_initiate_failed' ); | |
| 149 | + } | |
| 150 | + | |
| 151 | + // Cast because `wp_remote_retrieve_response_code()` hands back | |
| 152 | + // whatever the transport put there, and a numeric string fails the | |
| 153 | + // strict comparison below. On this route that is the worst place to | |
| 154 | + // get it wrong: a restore WordPress.com accepted would be reported | |
| 155 | + // as a failure, and the reader would start a second one. The long | |
| 156 | + // version is on `Rest_Controller::upstream_error()`. | |
| 157 | + $status_code = (int) wp_remote_retrieve_response_code( $response ); | |
| 158 | + if ( 200 !== $status_code ) { | |
| 159 | + return Rest_Controller::upstream_error( | |
| 160 | + $response, | |
| 161 | + 'restore_initiate_failed', | |
| 162 | + __( 'Could not start the backup restore.', 'jetpack-backup-pkg' ) | |
| 163 | + ); | |
| 164 | + } | |
| 165 | + | |
| 166 | + $decoded = json_decode( wp_remote_retrieve_body( $response ), true ); | |
| 167 | + if ( ! is_array( $decoded ) ) { | |
| 168 | + $decoded = array(); | |
| 169 | + } | |
| 170 | + | |
| 171 | + // `ok` is the success signal, not the presence of an id. | |
| 172 | + // | |
| 173 | + // VaultPress does not reliably echo a restore id back — the | |
| 174 | + // underlying call's documented response is only `{ ok, error }` — | |
| 175 | + // so `restore_id: null` means "queued, id not known yet", which is | |
| 176 | + // a perfectly good outcome. Reading the id as the signal reported | |
| 177 | + // a successfully queued restore as a 500, and could not have | |
| 178 | + // distinguished the two cases anyway: `(int) null` and `(int) 0` | |
| 179 | + // are both `0`. | |
| 180 | + if ( empty( $decoded['ok'] ) ) { | |
| 181 | + $data = array( 'status' => 500 ); | |
| 182 | + | |
| 183 | + // The `error` beside it is the whole of what went wrong — | |
| 184 | + // "There is already a restore in progress" and its like — and | |
| 185 | + // it was being dropped on the floor, leaving a reader who | |
| 186 | + // cannot start a second restore with no way to learn why. | |
| 187 | + // | |
| 188 | + // It arrives as prose with no machine code beside it, which is | |
| 189 | + // why `upstream_reason()` sorts on shape rather than on which | |
| 190 | + // key a value came from. The v2 route usually turns this | |
| 191 | + // answer into a 500 `rewind_error` before it ever reaches us, | |
| 192 | + // so what this branch catches is the shape upstream does not. | |
| 193 | + $reason = Rest_Controller::upstream_reason( $decoded ); | |
| 194 | + if ( ! empty( $reason ) ) { | |
| 195 | + $data['wpcom'] = $reason; | |
| 196 | + } | |
| 197 | + | |
| 198 | + return new WP_Error( | |
| 199 | + 'restore_initiate_failed', | |
| 200 | + __( 'Could not start the backup restore.', 'jetpack-backup-pkg' ), | |
| 201 | + $data | |
| 202 | + ); | |
| 203 | + } | |
| 204 | + | |
| 205 | + $restore_id_in = isset( $decoded['restore_id'] ) && null !== $decoded['restore_id'] | |
| 206 | + ? (int) $decoded['restore_id'] | |
| 207 | + : null; | |
| 208 | + | |
| 209 | + return rest_ensure_response( | |
| 210 | + array( | |
| 211 | + // Null is meaningful here and the client branches on it: | |
| 212 | + // the restore is running, and its id has to be recovered | |
| 213 | + // from the restores collection before progress can be | |
| 214 | + // polled. | |
| 215 | + 'id' => $restore_id_in, | |
| 216 | + 'rewind_id' => isset( $decoded['rewind_id'] ) ? (string) $decoded['rewind_id'] : $rewind_id, | |
| 217 | + ) | |
| 218 | + ); | |
| 219 | + } | |
| 220 | + | |
| 221 | + /** | |
| 222 | + * WPCOM's restore statuses, mapped to the vocabulary the client uses. | |
| 223 | + * | |
| 224 | + * Two engines write this field and the v2 route serves whichever ran: | |
| 225 | + * a Rewind restore — which is every restore this package starts — | |
| 226 | + * reports `queued | running | finished | fail`, a legacy VaultPress one | |
| 227 | + * `success | success-with-errors | aborted`. | |
| 228 | + * | |
| 229 | + * The Rewind half comes from Calypso's typed contract for this same | |
| 230 | + * endpoint, not from the v1 endpoint's docblock: that list omits | |
| 231 | + * `finished`, so every successful restore once reported `unknown`. | |
| 232 | + * | |
| 233 | + * Mapped here rather than in the client for the same reason the | |
| 234 | + * download bridge derives its own status: the wire vocabulary is | |
| 235 | + * WPCOM's to change, and one place to change it is better than three | |
| 236 | + * string comparisons scattered through a state machine. | |
| 237 | + * | |
| 238 | + * `success-with-errors` is deliberately kept distinct instead of being | |
| 239 | + * folded into either neighbour. A restore that completed but not | |
| 240 | + * cleanly is neither a success the reader should walk away from nor a | |
| 241 | + * failure they should retry blindly. | |
| 242 | + * | |
| 243 | + * @var array<string, string> | |
| 244 | + */ | |
| 245 | + private const STATUS_MAP = array( | |
| 246 | + 'queued' => 'queued', | |
| 247 | + 'running' => 'running', | |
| 248 | + 'finished' => 'finished', | |
| 249 | + 'fail' => 'failed', | |
| 250 | + 'success' => 'finished', | |
| 251 | + 'success-with-errors' => 'finished-with-errors', | |
| 252 | + 'aborted' => 'aborted', | |
| 253 | + ); | |
| 254 | + | |
| 255 | + /** | |
| 256 | + * Poll restore status. | |
| 257 | + * | |
| 258 | + * Proxies GET wpcom/v2 /sites/{blog_id}/rewind/restores/{restore_id}. | |
| 259 | + * | |
| 260 | + * Signed `as_blog`, unlike its sibling. Starting a restore is | |
| 261 | + * user-attributed and needs a user token; *watching* one does not — | |
| 262 | + * this route falls through to `is_jetpack_authorized_for_site()`, the | |
| 263 | + * same check the already-registered `GET /jetpack/v4/restores` relies | |
| 264 | + * on. That is a real capability gain rather than a shortcut: progress | |
| 265 | + * now survives the initiating user's session and is visible to any | |
| 266 | + * admin, which is exactly the failure mode where someone closes the | |
| 267 | + * tab mid-restore and can never see the outcome again. | |
| 268 | + * | |
| 269 | + * @param WP_REST_Request $request The REST request. | |
| 270 | + * @return \WP_REST_Response|WP_Error | |
| 271 | + */ | |
| 272 | + public static function get_restore_status( WP_REST_Request $request ) { | |
| 273 | + $blog_id = Rest_Controller::get_blog_id_or_error(); | |
| 274 | + if ( is_wp_error( $blog_id ) ) { | |
| 275 | + return $blog_id; | |
| 276 | + } | |
| 277 | + $restore_id = (int) $request->get_param( 'restore_id' ); | |
| 278 | + | |
| 279 | + $response = Client::wpcom_json_api_request_as_blog( | |
| 280 | + sprintf( '/sites/%d/rewind/restores/%d', $blog_id, $restore_id ), | |
| 281 | + 'v2', | |
| 282 | + array(), | |
| 283 | + null, | |
| 284 | + 'wpcom' | |
| 285 | + ); | |
| 286 | + | |
| 287 | + if ( is_wp_error( $response ) ) { | |
| 288 | + return Rest_Controller::transport_error( $response, 'restore_status_fetch_failed' ); | |
| 289 | + } | |
| 290 | + | |
| 291 | + // Cast, as in `initiate_restore()`. Both branches below depend on | |
| 292 | + // it: an uncast `'404'` would miss the queued-restore carve-out as | |
| 293 | + // well as the success test, so the ordinary opening seconds of a | |
| 294 | + // restore would surface as an error. | |
| 295 | + $status_code = (int) wp_remote_retrieve_response_code( $response ); | |
| 296 | + | |
| 297 | + // A 404 is the normal first answer, not a failure. A restore that | |
| 298 | + // has just been queued is not visible to this route yet, and the | |
| 299 | + // id may not even exist on our side (see `initiate_restore`, where | |
| 300 | + // VaultPress can decline to echo one). Reporting it as an error | |
| 301 | + // would turn the ordinary opening seconds of every restore into a | |
| 302 | + // user-visible failure. | |
| 303 | + // | |
| 304 | + // Reported as `not-found` and never as `queued`, which upstream | |
| 305 | + // also returns: the client reads the two the same way on screen | |
| 306 | + // but must not treat "no record of it" as a sign of life. | |
| 307 | + // | |
| 308 | + // Safe to treat softly only because the upstream route now | |
| 309 | + // answers 502 for an unparseable VaultPress reply — before that, a | |
| 310 | + // 404 could quietly have meant "upstream is down". | |
| 311 | + if ( 404 === $status_code ) { | |
| 312 | + return rest_ensure_response( self::project_status( array(), $restore_id, 'not-found' ) ); | |
| 313 | + } | |
| 314 | + | |
| 315 | + if ( 200 !== $status_code ) { | |
| 316 | + return Rest_Controller::upstream_error( | |
| 317 | + $response, | |
| 318 | + 'restore_status_fetch_failed', | |
| 319 | + __( 'Could not fetch restore progress.', 'jetpack-backup-pkg' ) | |
| 320 | + ); | |
| 321 | + } | |
| 322 | + | |
| 323 | + $body = json_decode( wp_remote_retrieve_body( $response ), true ); | |
| 324 | + // The v2 payload is flat. The old nested `restore_status` unwrap is | |
| 325 | + // kept because it is what makes the flat shape work too — the | |
| 326 | + // fallback branch is the live path now, not the defensive one. | |
| 327 | + $status = is_array( $body ) && isset( $body['restore_status'] ) && is_array( $body['restore_status'] ) | |
| 328 | + ? $body['restore_status'] | |
| 329 | + : ( is_array( $body ) ? $body : array() ); | |
| 330 | + | |
| 331 | + return rest_ensure_response( self::project_status( $status, $restore_id ) ); | |
| 332 | + } | |
| 333 | + | |
| 334 | + /** | |
| 335 | + * Shape a restore-status payload for the client. | |
| 336 | + * | |
| 337 | + * @param array $status Upstream status fields, possibly empty. | |
| 338 | + * @param int $fallback Restore id to report when upstream names none. | |
| 339 | + * @param string|null $force Status to report regardless of the payload. | |
| 340 | + * @return array | |
| 341 | + */ | |
| 342 | + private static function project_status( array $status, $fallback, $force = null ) { | |
| 343 | + $raw = isset( $status['status'] ) ? (string) $status['status'] : ''; | |
| 344 | + | |
| 345 | + if ( null !== $force ) { | |
| 346 | + $mapped = $force; | |
| 347 | + } elseif ( '' === $raw ) { | |
| 348 | + // A record that arrived without a status is queued and has not | |
| 349 | + // started reporting. An empty payload is not a record, and | |
| 350 | + // calling it `queued` would claim upstream is holding a | |
| 351 | + // restore it never mentioned — enough to refuse the reader a | |
| 352 | + // new one. Tested on emptiness rather than on one key, so a | |
| 353 | + // record spelled with fields we do not read still counts. | |
| 354 | + $mapped = empty( $status ) ? 'not-found' : 'queued'; | |
| 355 | + } else { | |
| 356 | + // Anything unrecognised is reported as such rather than | |
| 357 | + // guessed at. The client keeps polling through `unknown` under | |
| 358 | + // a bounded cap, so a status WPCOM adds later degrades into a | |
| 359 | + // slower answer instead of a frozen progress bar. | |
| 360 | + $mapped = self::STATUS_MAP[ $raw ] ?? 'unknown'; | |
| 361 | + } | |
| 362 | + | |
| 363 | + return array( | |
| 364 | + 'id' => isset( $status['restore_id'] ) ? (int) $status['restore_id'] : (int) $fallback, | |
| 365 | + 'status' => $mapped, | |
| 366 | + 'progress' => isset( $status['percent'] ) ? (float) $status['percent'] : 0, | |
| 367 | + 'rewind_id' => isset( $status['rewind_id'] ) ? (string) $status['rewind_id'] : '', | |
| 368 | + 'error_code' => isset( $status['error_code'] ) ? (string) $status['error_code'] : '', | |
| 369 | + 'message' => isset( $status['message'] ) ? (string) $status['message'] : '', | |
| 370 | + ); | |
| 371 | + } | |
| 372 | +} | |