https://svrforum.com/?_filter=search&vid=&mid=software&category=&search_target=title_content&search_keyword=webDAV+

여기 사이트 보니까  WebDAV 이거 이야기가 많더라구요 ㅎㅎ 그래서 많이 쓰는줄 알았습니다 ㅎㅎ

현재로서는 거의 NAS에서만 지원하는 방식이라 NAS가 있어야 하는데... 홈서버로 활용할 수 있는 NAS가 있다면 굳이 용량을 걱정해 가며 웹호스팅을 쓰지 않을 테니 수요층이 서로 안 맞죠. ㅎㅎ

기진곰님 이 애드온은 호불호가 있을꺼 같구요 혹시 자료실에 올려도 될지 모르겠습니다. 

이 댓글 보신분은 어떻게 하면 좋겠는지 여쭤봅니다. 자료실에 올려도 될지  궁금합니다.

지금까지 이런 종류의 기능을 안전하게 구현한 자료는 없었습니다. 혼자 쓴다면 몰라도, 다양한 환경에서 홈페이지를 운영하는 불특정 다수에게 배포한다면 파일 날려먹기 딱 좋죠. ㅎㅎ

애드온으로 구현하는 것은 더더욱 추천하지 않습니다. 단도직입적으로 말씀드릴게요. 모듈로 만들어도 신경써야 할 것이 많은데, 애드온 "따위"로는 이런 기능의 안전성을 보장하기가 아주아주 힘들 겁니다.

1) 사진이 서버에 저장되어 있지 않으면 썸네일 생성은 어떻게?
2) 파일 삭제도 연동해 주기

ㄴ 이 2가지에 대해서 헛점이였어요 고맙습니다 기능 추가  수정하고 있습니당 ^^ ㅎㅎ

에카님께서 말씀 주신걸  MCP에 적어서 줬더니 

 

맞아요, 정확한 지적이에요. 지금까지 만든 구조를 권한 관점에서 다시 짚어보면 이렇습니다.

지금 실제로 지켜지는 부분
"다운로드" 버튼(procFileDownload)은 백엔드가 뭐든 상관없이 FileModel::isDownloadable()을 거쳐서 스트리밍하기 전에 라이믹스 권한 체크를 통과해야 해요. 이건 5개 백엔드 전부 동일하게 지켜집니다.

지금 안 지켜지는 부분
게시글 본문에 박힌 <img> 같은 정적 서빙 폴백(serve_file.php)은 권한 체크가 전혀 없어요. rel_path만 맞으면 그냥 스트리밍합니다. 다만 이건 이 애드온이 새로 만든 구멍이 아니라 — 원래 라이믹스 자체가 direct_download='Y'인 파일(본문 삽입용)은 애초에 Apache가 PHP도 안 거치고 그냥 정적으로 서빙해버려서, 파일명이 추측 불가능한 해시라는 것에만 의존하는 "보안이 아니라 난독화" 방식이었어요. 저희 애드온은 그 기존 성격을 그대로 이어받은 것뿐이고, 옮기기 전이나 후나 이 지점의 보안 수준 자체는 달라진 게 없습니다.

진짜 새로 생기는 위험 — S3 public_url / 공개 WebDAV
말씀하신 대로 이게 핵심이에요. S3의 public_url 옵션이나 익명 읽기가 열린 WebDAV를 쓰면, 파일이 라이믹스 도메인이 아니라 S3/NAS 자체 도메인에서 직접 서빙돼요. 이러면:
- 라이믹스 권한 체크가 아예 개입할 방법이 없음 (요청이 우리 서버를 거치지도 않음)
- 게시글이 삭제되거나 비공개로 바뀌어도, 이미 알고 있는 URL은 계속 살아있음 (저희 삭제 연동이 지워주는 것도 원본 삭제 시점 기준이지, 이미 유출된 URL을 무효화할 방법은 없음)
- 말씀하신 대로 S3는 그나마 서명 URL(signed URL, 시간제한+매 요청 발급)로 이 문제를 피할 수 있는데, FTP/WebDAV는 HTTP 자체가 아니거나(FTP) 서명 URL 개념이 없어서 이 완화책이 통하지 않아요. FTP/SFTP는 반대로 HTTP가 아예 아니라서 오히려 "무조건 저희 PHP를 거쳐야만 접근 가능"이라는 강제성이 있긴 한데, 그 PHP 경유 지점(serve_file.php)에 지금 권한 체크가 없다는 게 위 문단의 구멍이고요.

정리하면 손볼 수 있는 부분과 못 손보는 부분이 갈려요:
1. 고칠 수 있는 것: serve_file.php에도 isDownloadable() 같은 권한 체크를 추가해서, 최소한 "우리 PHP를 거치는" local/ftp/webdav(비공개)/sftp/S3(서명) 경로는 게시판 읽기 권한이 없는 사람에게 막을 수 있어요.
2. 구조적으로 못 고치는 것: S3 public_url이나 공개 WebDAV처럼 제3자 도메인이 직접 서빙하는 방식은 애초에 라이믹스가 개입할 지점이 없어서, 코드로 해결이 안 되고 "그 저작권 민감한 게시판 같은 곳엔 public_url/공개 WebDAV를 쓰지 말고 서명 S3나 비공개 FTP/SFTP만 쓴다"는 운영 정책으로만 막을 수 있어요.

1번(serve_file.php 권한 체크 추가)은 지금 바로 코드로 넣어드릴 수 있는데, 하시겠어요? 2번은 관리자 설정 화면에 경고 문구 정도는 추가할 수 있어요.

라고 말해주는데 어렵네요 ㅋㅋㅋ

완벽하게 만들기는 솔직히 불가능은 아닌데 난이도가 급격하게 올라가요.

애드온으로 유용한 사용자층은 웹호스팅 이용하는분들인데, 이분들에게는 배보다는 배꼽이 더 커지는 상황일거에요.

제가 더  좋은 아이디어가 떠오르지가 않네요 아는 기술이 없고 무지해서..ㅠㅠ

## v0.7.2 (2026-07-21) — 정적 서빙 폴백에 게시판 읽기 권한 체크 추가

### 배경
사용자 지적: 파일을 S3/FTP/WebDAV/SFTP처럼 라이믹스가 아니면 접근이 아예
불가능한 저장소로 옮기고 나면, 그 파일에 대한 유일한 접근 경로가
`serve_file.php`의 정적 서빙 폴백인데 여기엔 권한 체크가 전혀 없었음.
다운로드 버튼(`procFileDownload`)은 항상 `FileModel::isDownloadable()`을
거치지만, 게시글 본문에 박힌 `<img>` 태그가 트리거하는 이 폴백 경로는
비어있었음.

(원래 라이믹스 자체도 `direct_download='Y'` 파일은 Apache가 PHP도 안 거치고
정적으로 서빙해서 이 지점엔 원래부터 권한 체크가 없었음 — 해시 파일명이라는
"난독화"에만 의존하는 구조. 이 애드온이 새로 만든 구멍은 아니지만, 저작권
민감 게시판처럼 진짜 접근 제어가 필요한 경우엔 문제가 될 수 있음.)

### 해결
- `serve_file.php`에 `LefServe::isPermitted()` 추가. 매핑 테이블에서
  file_srl을 알 수 있는 경우(=v0.7.0 이후 방식으로 이동된 파일)에 한해:
  - `FileModel::isDownloadable()` (isvalid, download_groups 설정) 확인
  - 첨부파일이 걸린 게시글(`DocumentModel::getDocument()->isAccessible()`)
    또는 댓글의 읽기 권한 확인
  - 권한이 없으면 스트리밍을 거부하고 코어 404 처리로 넘김
- 레거시(마이그레이션 안 된) 데이터는 file_srl을 알 수 없어 이 체크를
  건너뜀 — 관리자 복구 탭의 "레거시 항목 정리"로 매핑 테이블에 올리면
  이 파일들도 체크 대상이 됨

### 한계 (코드로 해결 불가능, 운영 정책으로만 대응 가능)
S3 `public_url`(공개 버킷)이나 익명 읽기가 열린 WebDAV처럼 **제3자 도메인이
직접 서빙**하는 방식은 요청이 라이믹스 서버를 아예 거치지 않으므로, 이번
수정과 무관하게 여전히 권한 체크가 불가능함. S3는 서명 URL(signed URL)로
완화 가능하지만 FTP/일반 WebDAV는 그런 개념 자체가 없어 근본적으로 막을
방법이 없음. 접근 제어가 중요한 게시판(저작권 민감 게시판 등)은
public_url/공개 WebDAV를 쓰지 말고, 서명 S3나 비공개 FTP/SFTP/WebDAV만
사용할 것 — 이건 코드가 아니라 운영 시 선택의 문제.

---


에카님 이게 지금 맞게 된건질  모르겠어요 

아하 알겠습니다 

작업 지시: "첨부파일 외부로" 애드온 → 모듈 전환 (v1.0.0 신규)
배경 / 타겟
기존 애드온(lua_external_file)은 홈서버 사용자 대상 로컬/마운트 경로 이동 기능이었음
이번 작업은 타겟을 바꿔서 **웹호스팅 사용자(NAS 없음, 용량 비용 절감이 목적)**를 겨냥함
기존 애드온 코드는 참고만 하고, 모듈 구조로 완전히 새로 설계할 것 (재활용 안 함)
버전은 기존 이력과 별개로 모듈 v1.0.0으로 새출발
지원 저장소 (범위 확정)
S3 호환 오브젝트 스토리지 (AWS S3, Backblaze B2, Cloudflare R2, MinIO 등) — SigV4 직접 구현, SDK 의존성 없이
FTP — PHP 내장 함수만 사용, 의존성 없음
WebDAV, SFTP는 이번 범위에서 제외 (커뮤니티 피드백 기준: 타겟 유저층과 안 맞음 / phpseclib 번들링 부담)
모듈 구조 필수 요소
schema/*.xml — 파일↔외부경로 매핑 테이블 자동 설치 (file_srl, storage_type, remote_path, migrated_at, status 등)
module.xml에 insertTrigger로 file.insertFile / file.deleteFile 훅 등록
관리자 화면: 저장소별 설정, 연결 테스트 버튼, 매핑 목록 조회, 레거시 항목 정리(마이그레이션 안 된 데이터 처리)
업로드 직후 이동 (원격 저장소는 다운로드 시점 이동 X — 네트워크 지연 방지)
필수 해결 과제 (커뮤니티 피드백 반영, 미루면 안 됨)
썸네일 생성: 원본이 서버에 없을 때 썸네일을 언제/어디서 생성·캐싱할지 설계 필요
파일 삭제 연동: 게시글/파일 삭제 시 원격 저장소에서도 삭제되도록, 실패 시 재시도 로직 포함
serve_file.php 권한 체크: 게시글 본문 <img> 등 정적 서빙 폴백 경로에 FileModel::isDownloadable() + 게시글/댓글 읽기 권한 체크 추가 (다운로드 버튼은 이미 체크하지만 이 경로는 뚫려 있었음)
S3는 signed URL 방식 강제/권장, public_url(공개 버킷)은 관리자 설정에 경고 문구 표시 — FTP는 애초에 HTTP가 아니라 PHP를 반드시 거치므로 이 문제 자체가 없음
설계 원칙
애드온 시절의 "가볍게, 의존성 최소" 철학 유지하되, 상태 추적(매핑 테이블)과 관리자 가시성은 모듈 수준으로 끌어올릴 것
불특정 다수 배포 목적이므로 "혼자 쓸 때는 괜찮았던" 안일한 처리(레거시 데이터 미체크, 권한 누락 등)는 전부 재검토

오늘 퇴근후 재작업 하겠습니다 ㅎㅎ