인터뷰에서 방향만 정하고 남겨 뒀던 후속 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
77 lines
3.0 KiB
PHP
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 키 원문이 그대로 노출됩니다."
|
|
);
|
|
}
|
|
}
|
|
}
|
|
}
|
|
}
|