Files
Gnuboard7/tests/Feature/Identity/CorePurposeRegistryParityTest.php
T
HeuJung 7b56d5f23a feat(core,board,ecommerce,page,ckeditor5,kginicis): 업로드 이미지 축소·로그인 2단계 인증 도입 + 파생 결함 수정
인터뷰에서 방향만 정하고 남겨 뒀던 후속 5건을 구현하고, 커밋 전 종합 점검에서
발견한 결함 2건을 함께 고쳤다.

기능 도입:
- 업로드 이미지 축소 — `upload.image_max_width` / `image_max_height` / `image_quality`
 는 저장·검증만 되고 리사이즈 코드가 0건이었다. 비율 유지, 상한 이내면 재인코딩하지
 않음(불필요한 화질 손실 방지), 한계 미설정이면 무동작(기존 사이트 이미지 보호).
 PNG·GIF·WebP 투명도 보존. 실패해도 업로드는 계속되고 원본이 저장된다.
- 로그인 2단계 인증 — `security.two_factor_auth` 는 설정 항목만 있고 구현도 화면
 컨트롤도 없었다. 코어 IDV 인프라를 재사용해 purpose `login` 을 추가하고, 비밀번호
 확인 통과 후 challenge 만 발행한다(토큰 미발급 + logout). `POST /api/auth/login/two-factor`
 가 코드를 확인해야 토큰이 나가며, 로그인과 같은 요청 제한을 적용한다. challenge 의
 purpose 를 대조해 다른 흐름의 challenge 로 로그인하는 것을 막는다. 코드 발송이
 실패하면 실패로 알린다 — 2단계를 건너뛰고 로그인시키면 통제가 조용히 열린다.

결함 수정:
- 게시글 수정 시 사용자 경로가 `attachment_ids` 를 Service 로 넘기지 않아, 검증과
 권한은 통과하고 200 을 받는데 첨부만 조용히 연결되지 않았다. 관리자 경로는 넘기고
 있어 같은 요청이 화면에 따라 다르게 동작했다.
- 설정 화면 라디오가 `pointer-events-none` + Label click 으로만 상태를 바꿔, 키보드
 방향키(change) 조작 시 화면 표시와 저장될 값이 어긋났다. 동일 패턴 4개 레이아웃
 12개 라디오에 change 액션을 부여하고 params 를 click 과 동일하게 고정한다.
- 주문완료 화면이 결제수단 확인보다 영수증 조회를 앞세워, PG 를 거치지 않는 주문에서도
 매번 404 요청이 나갔다.
- 개별 게시판 폼의 숫자 항목에 경계값 바인딩이 없어 환경설정 화면과 안내가 달랐다.

커밋 전 점검에서 발견:
- 2단계 인증이 반쪽으로 들어가 있었다. enum 에 case 만 추가하고 코어 purpose
 레지스트리와 ko/en 라벨을 빠뜨려, 목적 목록 API 에서 통째로 빠지고 `hasPurpose`
 가 false 였으며 라벨 대신 i18n 키 원문이 반환됐다. 관리자가 이 목적의 메시지
 템플릿·정책을 만들 수 없는 상태였다. 세 곳을 enum 기준으로 전수 대조하는 회귀
 테스트를 함께 둔다.
- 업로드 이미지 축소가 적용되지 않은 8번째 서비스(레이아웃 편집기 첨부)가 있었다.
 열거형 커버리지 테스트는 내 조사 결과를 green 으로 고정할 뿐 전수를 증명하지
 못한다 — 같은 규약을 조건으로 표현한 audit 룰이 첫 실행에서 검출했다.

재발 방지:
- audit 룰 `upload-service-image-resize` (신규 업로드 서비스의 축소 누락 검출)
- 트러블슈팅 사례 20 (코어 설정이 일부 경로에만 적용되는 증상의 진단 절차)
- `sirsoft-ckeditor5` 의 코어 최소 요구 버전을 7.0.6 으로 상향 (신설 클래스 의존)

공개 이슈: gnuboard/g7
2026-07-30 07:57:06 +09:00

77 lines
3.0 KiB
PHP

<?php
namespace Tests\Feature\Identity;
use App\Enums\IdentityVerificationPurpose;
use App\Extension\IdentityVerification\IdentityVerificationManager;
use PHPUnit\Framework\Attributes\Test;
use Tests\TestCase;
/**
* 코어 purpose 계약 정합성 테스트
*
* 코어 purpose 는 세 곳에 동시에 존재해야 온전히 동작합니다.
*
* 1. `IdentityVerificationPurpose` enum — 코드에서 참조하는 값
* 2. `IdentityVerificationManager::$corePurposes` — 관리자 화면·API 가 읽는 목록
* 3. `lang/{ko,en}/identity.php` 의 `purposes.{value}` — 사람이 읽는 라벨
*
* 실측(2026-07-29): 2단계 인증을 도입하며 enum 에 `login` 만 추가하고 2·3 을 빠뜨렸다.
* 그 결과 `hasPurpose('login')` 이 false 였고, `getAllPurposes()` 에서 빠져 관리자가
* 이 목적의 메시지 템플릿·정책을 만들 수 없었으며, `Login->label()` 은 라벨 대신
* `identity.purposes.login.label` 이라는 i18n 키 원문을 그대로 돌려줬다.
*
* 셋 중 하나만 빠져도 조용히 반쪽 동작하므로 값 목록을 하드코딩하지 않고
* enum 을 기준으로 나머지 둘을 전수 대조한다 — 새 purpose 를 추가하면 자동으로 검사 대상이 된다.
*/
class CorePurposeRegistryParityTest extends TestCase
{
#[Test]
public function every_core_purpose_is_registered_in_the_manager(): void
{
$registered = array_keys(app(IdentityVerificationManager::class)->getAllPurposes());
foreach (IdentityVerificationPurpose::values() as $purpose) {
$this->assertContains(
$purpose,
$registered,
"purpose '{$purpose}' 가 corePurposes 레지스트리에 없습니다 — 관리자가 이 목적의 메시지 템플릿·정책을 만들 수 없습니다."
);
}
}
#[Test]
public function every_core_purpose_answers_true_to_has_purpose(): void
{
$manager = app(IdentityVerificationManager::class);
foreach (IdentityVerificationPurpose::values() as $purpose) {
$this->assertTrue(
$manager->hasPurpose($purpose),
"hasPurpose('{$purpose}') 가 false 입니다 — 코어 purpose 인데 등록되지 않은 것으로 취급됩니다."
);
}
}
#[Test]
public function every_core_purpose_resolves_a_label_and_description_in_each_base_locale(): void
{
foreach (['ko', 'en'] as $locale) {
$this->app->setLocale($locale);
foreach (IdentityVerificationPurpose::cases() as $case) {
foreach (['label', 'description'] as $field) {
$key = "identity.purposes.{$case->value}.{$field}";
$translated = __($key);
$this->assertNotSame(
$key,
$translated,
"[{$locale}] {$key} 번역이 없습니다 — 화면에 i18n 키 원문이 그대로 노출됩니다."
);
}
}
}
}
}