HeuJung
3945b6f1b3
공개 저장소 이슈 gnuboard/g7 (@bigmsg) 제보에서 출발한 작업이다. 브라우저가 화면을 그리려고 제3자 CDN 에 도달해야 하면, 그 도달 실패는 예외도 로그도 남기지 않고 화면 기능만 조용히 사라진다. 폐쇄망·방화벽·광고차단기에서 재현되는데 자체 서버 로그에는 흔적이 없어 운영자가 원인을 특정할 수 없다. 제보된 것은 편집기 하나였지만 같은 구조가 아이콘·글꼴·코드편집기·압축 라이브러리·설치 마법사·개발 대시보드에 똑같이 있었으므로, 번들 확장과 템플릿 전체를 자체 제공으로 옮겼다. 런타임에 외부로 나가는 것은 주소 검색 서비스 하나만 남았다. 자체 제공만으로는 부족하다 — 자기 서버에서 받는 파일도 실패할 수 있고, 종전에는 그 실패가 무음이었다. CSS 경로에 재시도 계층을 세우고(스크립트 경로와 동형), 서버가 HTML 에 직접 심는 externals 까지 실패를 붙잡아 안내 배너와 [다시 시도]로 표면화했다. 편집기·코드편집기는 확보 실패 시 평문 입력으로 내려앉되 저장 계약을 유지한다. 두 번째 축은 운영자가 CSS 를 덧붙일 자리가 없던 문제다(sir.kr 문의). 확장 디렉토리의 custom/ 을 운영자 소유로 정해, 확장 교체가 그 디렉토리만은 보존하게 했다. 출처에 의존하지 않는 서술자로 해석하므로 나중에 다른 출처가 붙어도 소비자는 바뀌지 않는다. 확장 자산과 같은 메커니즘으로 정적 게시되어 CSS 내부 상대 url 도 해석되고, 파일을 고치면 그 변경을 감지해 재게시까지 예약된다. FTP 접근이 없는 운영자에게는 그 자리도 없는 것과 같으므로 레이아웃 편집기에서 직접 넣고 고칠 수 있게 했다. 모듈·플러그인·템플릿이 한 엔드포인트를 공유한다 — 타입별로 나누면 같은 검증이 세 벌로 갈리고 그중 약한 하나가 우회로가 된다. 여기서 올린 스크립트는 그 레이아웃 한 장이 아니라 사이트 전 화면에서 실행되므로 레이아웃 편집과 분리된 전용 권한으로 연다. 운영자 CSS 가 화면을 조작 불능으로 만들면 그것을 고칠 화면에도 같은 CSS 가 실려 스스로 갇히므로, 서버가 목록을 비우는 탈출구(?custom=off)를 함께 뒀다. 동봉 자산은 재생성 경로에 버전 대조 가드를 붙였다. 선언과 다른 버전을 버전 디렉토리에 써 넣는 조용한 거짓말은 배포된 뒤에는 드러나지 않는다.
82 lines
4.9 KiB
YAML
82 lines
4.9 KiB
YAML
feature: 사용자 추가 에셋 화면 관리 (레이아웃 편집기 + 전용 권한)
|
|
|
|
description: |
|
|
운영자가 자기 CSS·JS·폰트·이미지를 **화면에서** 넣고 고칠 수 있게 한다.
|
|
|
|
종전에는 FTP 나 서버 셸이 유일한 경로였다 — 그 접근이 없는 운영자에게는 기능 자체가
|
|
없는 것과 같았고, 있는 운영자에게도 "고쳤는데 화면에 안 나온다"(정적 게시본 미갱신)가
|
|
남았다.
|
|
|
|
핵심 동작:
|
|
- 전용 권한(`core.extensions.custom_assets.manage`) 하나가 세 확장 타입의 관리 API 를 가드한다
|
|
- 레이아웃 편집 권한만으로는 통과하지 못한다 (여기서 올린 스크립트는 사이트 전역에서 실행된다)
|
|
- 모듈·플러그인·템플릿이 한 엔드포인트(`extensions/{type}/{id}/custom-assets`)를 공유한다
|
|
- 텍스트(css/js/mjs/json)는 본문 편집, 그 밖(폰트·이미지)은 업로드·삭제만
|
|
- 쓰기 뒤 확장 캐시 버전을 올려 정적 게시본을 갱신한다
|
|
- 경로 탈출은 세그먼트 판정으로 차단한다 (문자열 접두 비교는 형제 디렉토리를 통과시킨다)
|
|
- `?custom=off` 로 다시 열면 서버가 목록을 비운다 — 자기 CSS 에 갇히지 않기 위한 탈출구
|
|
|
|
이 기능의 결함은 대체로 오류를 남기지 않는다. 약한 경로가 정상 200 을 내보내는 것이
|
|
유일한 증상이므로 테스트가 유일한 방어선이다.
|
|
|
|
coverage_strategy: pairwise
|
|
|
|
axes:
|
|
manage_actor: [with_permission, layout_edit_only, unauthenticated]
|
|
manage_action: [list, read, save, upload, delete]
|
|
|
|
exclusions:
|
|
- { manage_actor: unauthenticated, manage_action: read, reason: "인증 게이트가 동작 종류보다 앞이라 list 1건으로 대표된다" }
|
|
- { manage_actor: unauthenticated, manage_action: save, reason: "동일" }
|
|
- { manage_actor: unauthenticated, manage_action: upload, reason: "동일" }
|
|
- { manage_actor: unauthenticated, manage_action: delete, reason: "동일" }
|
|
- { manage_actor: layout_edit_only, manage_action: upload, reason: "권한 미들웨어가 라우트별로 동일해 list/read/save 3건으로 대표된다" }
|
|
- { manage_actor: layout_edit_only, manage_action: delete, reason: "동일" }
|
|
|
|
effects:
|
|
- custom_asset_manage_requires_dedicated_permission
|
|
- custom_asset_manage_path_traversal_blocked
|
|
- custom_asset_manage_upload_extension_whitelist
|
|
- custom_asset_manage_binary_rejects_text_save
|
|
- custom_asset_editor_save_invalidates_published_copy
|
|
- custom_asset_manager_surfaces_permission_denial_as_guidance
|
|
- custom_asset_binary_file_offers_replace_not_text_edit
|
|
- custom_asset_permission_reaches_existing_sites_via_core_sync
|
|
- custom_assets_disabled_by_request_parameter
|
|
- custom_asset_manage_all_extension_types_parity
|
|
- custom_asset_published_for_all_extension_types
|
|
|
|
test_files:
|
|
- tests/Feature/Api/Admin/AdminExtensionCustomAssetControllerTest.php
|
|
- tests/Feature/Permission/CustomAssetPermissionSyncTest.php
|
|
- tests/Feature/View/CustomAssetInjectionTest.php
|
|
- resources/js/core/template-engine/layout-editor/__tests__/components/CustomAssetsModal.test.tsx
|
|
- tests/Playwright/specs/custom-asset-management.spec.ts
|
|
- tests/Feature/Services/ExtensionStaticCacheServiceTest.php
|
|
|
|
sub_flows:
|
|
- id: custom_manage_type_parity
|
|
description: |
|
|
세 확장 타입이 같은 강도로 동작해야 한다. 타입별로 경로·검증이 갈리면 그중 약한 쪽이
|
|
조용한 우회로가 되고, 반대로 한 타입만 동작하면 운영자는 "모듈에서는 왜 안 되는지" 를
|
|
알 수 없다.
|
|
|
|
게시 축도 같다 — 모듈·플러그인 `custom/` 을 게시하지 않으면 그쪽만 CSS 내부 상대
|
|
`url()` 이 해석되지 않는다(그 자산만 요청마다 PHP 를 거치는 것은 부수 효과다).
|
|
- id: custom_manage_no_upgrade_step_needed
|
|
description: |
|
|
신규 권한은 별도 업그레이드 스텝 없이 코어 업데이트의 표준 동기화
|
|
(`CoreUpdateService::syncCoreRolesAndPermissions`)로 기설치 사이트에 도달한다.
|
|
관리자 역할이 `all_leaf` 이므로 부여까지 자동이다.
|
|
|
|
그 전제가 사실인지를 테스트가 잠근다 — 사실이 아니면 권한이 정의만 되고 아무에게도
|
|
부여되지 않아, 화면은 정상인데 모두 403 이 된다.
|
|
- id: custom_manage_escape_hatch
|
|
description: |
|
|
운영자가 넣은 CSS 한 줄이 화면을 조작 불능으로 만들면, 그것을 고칠 편집기에도
|
|
같은 CSS 가 실려 스스로 갇힌다. `?custom=off` 는 **서버가** 목록을 비우는 방식이라
|
|
이미 깨진 화면에서 자바스크립트가 돌기를 기대하지 않아도 된다.
|
|
|
|
판정은 수집 맨 앞에 있어야 한다 — 뒤에 두면 빈 목록이 변경 감지에 도달해 요청마다
|
|
캐시 버전이 오르내리고 재게시가 끝없이 돈다.
|