공개 저장소 이슈 gnuboard/g7 (@bigmsg) 제보에서 출발한 작업이다. 브라우저가 화면을 그리려고 제3자 CDN 에 도달해야 하면, 그 도달 실패는 예외도 로그도 남기지 않고 화면 기능만 조용히 사라진다. 폐쇄망·방화벽·광고차단기에서 재현되는데 자체 서버 로그에는 흔적이 없어 운영자가 원인을 특정할 수 없다. 제보된 것은 편집기 하나였지만 같은 구조가 아이콘·글꼴·코드편집기·압축 라이브러리·설치 마법사·개발 대시보드에 똑같이 있었으므로, 번들 확장과 템플릿 전체를 자체 제공으로 옮겼다. 런타임에 외부로 나가는 것은 주소 검색 서비스 하나만 남았다. 자체 제공만으로는 부족하다 — 자기 서버에서 받는 파일도 실패할 수 있고, 종전에는 그 실패가 무음이었다. CSS 경로에 재시도 계층을 세우고(스크립트 경로와 동형), 서버가 HTML 에 직접 심는 externals 까지 실패를 붙잡아 안내 배너와 [다시 시도]로 표면화했다. 편집기·코드편집기는 확보 실패 시 평문 입력으로 내려앉되 저장 계약을 유지한다. 두 번째 축은 운영자가 CSS 를 덧붙일 자리가 없던 문제다(sir.kr 문의). 확장 디렉토리의 custom/ 을 운영자 소유로 정해, 확장 교체가 그 디렉토리만은 보존하게 했다. 출처에 의존하지 않는 서술자로 해석하므로 나중에 다른 출처가 붙어도 소비자는 바뀌지 않는다. 확장 자산과 같은 메커니즘으로 정적 게시되어 CSS 내부 상대 url 도 해석되고, 파일을 고치면 그 변경을 감지해 재게시까지 예약된다. FTP 접근이 없는 운영자에게는 그 자리도 없는 것과 같으므로 레이아웃 편집기에서 직접 넣고 고칠 수 있게 했다. 모듈·플러그인·템플릿이 한 엔드포인트를 공유한다 — 타입별로 나누면 같은 검증이 세 벌로 갈리고 그중 약한 하나가 우회로가 된다. 여기서 올린 스크립트는 그 레이아웃 한 장이 아니라 사이트 전 화면에서 실행되므로 레이아웃 편집과 분리된 전용 권한으로 연다. 운영자 CSS 가 화면을 조작 불능으로 만들면 그것을 고칠 화면에도 같은 CSS 가 실려 스스로 갇히므로, 서버가 목록을 비우는 탈출구(?custom=off)를 함께 뒀다. 동봉 자산은 재생성 경로에 버전 대조 가드를 붙였다. 선언과 다른 버전을 버전 디렉토리에 써 넣는 조용한 거짓말은 배포된 뒤에는 드러나지 않는다.
97 lines
3.5 KiB
PHP
97 lines
3.5 KiB
PHP
<?php
|
|
|
|
namespace Tests\Unit\Resources;
|
|
|
|
use App\Extension\Traits\ClearsTemplateCaches;
|
|
use App\Http\Resources\TemplateResource;
|
|
use App\Support\TemplateExternals;
|
|
use Tests\TestCase;
|
|
|
|
/**
|
|
* TemplateResource externals 정규화 테스트
|
|
*
|
|
* `asset`(템플릿이 자체 제공하는 `dist/` 이하 경로) 항목은 URL 을 만들 때
|
|
* 식별자와 캐시 버전을 요구한다. 리소스가 그 둘을 넘기지 않으면 항목이
|
|
* "식별자 미상" 으로 **조용히 버려져** 응답에서 사라진다 — 예외도 오류도
|
|
* 남지 않고 필드만 빈 배열이 된다.
|
|
*
|
|
* 뷰 컴포저(CollectsTemplateExternals)와 이 리소스는 같은 정규화기를 쓰는
|
|
* 두 소비자다. 한쪽만 인자를 갖추면 화면은 정상인데 API 만 비는 비대칭이
|
|
* 생기므로, 두 경로가 같은 결과를 내는지까지 잠근다.
|
|
*/
|
|
class TemplateResourceExternalsTest extends TestCase
|
|
{
|
|
/**
|
|
* `asset` externals 를 선언한 템플릿 manifest 조각을 만듭니다.
|
|
*
|
|
* @return array<string, mixed> 리소스 입력용 배열
|
|
*/
|
|
private function templatePayload(): array
|
|
{
|
|
return [
|
|
'id' => 1,
|
|
'identifier' => 'test-assetexternals',
|
|
'externals' => [
|
|
[
|
|
'id' => 'fontawesome',
|
|
'type' => 'style',
|
|
'asset' => 'vendor/font-awesome/6.4.0/css/all.inlined.css',
|
|
],
|
|
[
|
|
'id' => 'pretendard',
|
|
'type' => 'webfont',
|
|
'asset' => 'vendor/pretendard/1.3.9/pretendard-variable.css',
|
|
],
|
|
],
|
|
];
|
|
}
|
|
|
|
/**
|
|
* `asset` 항목이 응답에서 사라지지 않는지 확인합니다.
|
|
*/
|
|
public function test_asset_externals_survive_detail_serialization(): void
|
|
{
|
|
$externals = (new TemplateResource($this->templatePayload()))->toDetailArray()['externals'];
|
|
|
|
$this->assertCount(2, $externals, '`asset` externals 가 응답에서 버려졌다 (식별자 미전달)');
|
|
$this->assertSame(
|
|
['fontawesome', 'pretendard'],
|
|
array_column($externals, 'id')
|
|
);
|
|
}
|
|
|
|
/**
|
|
* 해석된 URL 이 same-origin 인지 확인합니다.
|
|
*/
|
|
public function test_asset_externals_resolve_to_same_origin_urls(): void
|
|
{
|
|
$externals = (new TemplateResource($this->templatePayload()))->toDetailArray()['externals'];
|
|
|
|
foreach ($externals as $item) {
|
|
$url = $item['url'] ?? $item['href'] ?? '';
|
|
|
|
$this->assertStringStartsWith('/', $url, '자체 제공 자산이 same-origin 경로로 해석되지 않았다');
|
|
$this->assertStringNotContainsString('//', ltrim($url, '/'), 'protocol-relative URL 로 해석되었다');
|
|
}
|
|
}
|
|
|
|
/**
|
|
* 리소스 경로와 뷰 컴포저 경로가 같은 결과를 내는지 확인합니다.
|
|
*
|
|
* 두 소비자가 어긋나면 화면은 정상인데 API 만 비는 비대칭이 생긴다.
|
|
*/
|
|
public function test_resource_matches_view_composer_normalization(): void
|
|
{
|
|
$payload = $this->templatePayload();
|
|
|
|
$fromResource = (new TemplateResource($payload))->toDetailArray()['externals'];
|
|
$fromComposerPath = TemplateExternals::normalize(
|
|
$payload['externals'],
|
|
$payload['identifier'],
|
|
ClearsTemplateCaches::getExtensionCacheVersion(),
|
|
);
|
|
|
|
$this->assertEquals($fromComposerPath, $fromResource);
|
|
}
|
|
}
|