학생 데이터, 모으기 전에

📋 복사현재 웹앱의 교사 대시보드를 브라우저 소스를 전부 확인해도 뚫리지 않도록
Supabase Auth와 RLS를 사용한 구조로 변경해 줘.
단순히 로그인 화면을 보여 주거나 JavaScript로 대시보드를 숨기는 것에서 끝내지 말고,
데이터베이스에서 실제 읽기 요청을 차단해야 해.
현재 프로젝트의 전체 코드를 먼저 확인한 뒤 아래 조건을 적용해.

## 1. 기존 클라이언트 비밀번호 방식 완전 삭제
HTML·JavaScript 전체에서 다음을 찾아 제거해.
- TEACHER_PIN / ADMIN_PASSWORD / DASHBOARD_PASSWORD
- 코드에 직접 적힌 비밀번호 문자열
- 입력값과 고정 문자열을 비교하는 코드
- 암호화/해시한 값을 브라우저에서 비교하는 코드
- URL 파라미터만으로 관리자 여부를 판단하는 코드
- localStorage의 isTeacher, isAdmin 값만으로 권한을 판단하는 코드
- 숨겨진 관리자 버튼·특정 키 입력만으로 잠금 해제하는 코드
브라우저 코드 어디에도 실제 비밀번호(정답)가 남아 있으면 안 돼.

## 2. Supabase Auth 로그인 적용
교사 로그인 화면: 이메일·비밀번호 입력, 로그인/로그아웃 버튼, 진행 상태, 실패 안내, 현재 로그인 상태.
로그인은 supabase.auth.signInWithPassword({ email, password }) 사용.
페이지 진입 시 세션 확인 + 로그인 상태 변화 감지:
- supabase.auth.getSession()
- supabase.auth.onAuthStateChange(...)
- supabase.auth.signOut()
현재 쓰는 supabase-js 버전에 맞게 적용해.
회원가입 버튼을 만들지 말고 supabase.auth.signUp()도 쓰지 마.
교사 계정은 Dashboard의 Authentication → Users에서 미리 만든 계정만 사용.
localStorage에 isTeacher=true 같은 값을 저장해 권한 판정하지 마.

## 3. 로그인 전에는 학생 데이터를 요청하지 않기
로그인 안 한 상태에서는 대시보드·학생 데이터 표를 보여 주지 마.
화면만 숨기고 백그라운드에서 미리 불러오지도 마.
학생 데이터 select 요청은 교사 로그인 세션 확인 후에만 실행.
로그아웃하면: 화면의 학생 데이터 제거, 대시보드 숨김, 로그인 화면 표시,
교사 전용 실시간 구독 해제, 더 이상 select 요청 안 보냄.

## 4. RLS로 지정된 교사 UID만 조회 허용
학생 데이터가 저장되는 실제 테이블명을 확인해(예시명 그대로 쓰지 마).
그 테이블 RLS 활성화 + 기존 select 정책 전부 확인.
anon/public 또는 모든 authenticated가 읽게 만든 정책이 있으면 제거/교체.
교사 UID를 사용하는 select 정책 작성:

alter table public.[실제_테이블명] enable row level security;

create policy "designated teacher can read"
on public.[실제_테이블명]
for select
to authenticated
using ( (select auth.uid()) = '[교사 계정 UID]' );

중요:
- to authenticated using (true) 로 만들지 마.
- authenticated는 교사 역할이 아니라 로그인한 모든 사용자를 뜻해.
- 반드시 auth.uid()와 지정한 교사 UID를 비교해.
- 실제 교사 UID를 어디에 붙여 넣는지 설명해.
- 충돌·중복되는 기존 select 정책이 있는지 확인하고, 위험한 정책을 남기지 마
  (허용 정책 하나만 남아도 OR처럼 작동할 수 있음).

## 5. 학생의 익명 제출은 유지
학생은 로그인 없이 기존 제출 화면에서 제출할 수 있어야 해.
학생 제출은 anon 역할에 insert만 허용:

create policy "anonymous students can submit"
on public.[실제_테이블명]
for insert
to anon
with check ( [현재 열 구조에 맞는 값 검증 조건] );

학생에게 select/update/delete 권한은 주지 마.
학생 제출 코드가 .insert(data).select() 라면
select 권한이 없어도 작동하도록 .insert(data) 로 바꿔.
단, 반환값이 꼭 필요한 구조면 무조건 지우지 말고 안전한 대안을 제시해.

## 6. 프런트엔드 키 점검
정상: Supabase URL, publishable key, anon key.
절대 포함 금지: service_role key, secret key, sb_secret 키,
데이터베이스 비밀번호, 교사 로그인 비밀번호.
HTML·JavaScript·환경 파일·GitHub 저장소를 모두 점검.
정적 사이트의 환경변수도 빌드 후 브라우저 코드에 포함될 수 있으니
'환경변수'라는 이유만으로 비밀이라 판단하지 마.

## 7. 회원가입 기능 차단
회원가입 UI를 만들지 마. 교사 계정은 Dashboard에서 관리자가 미리 생성.
Authentication 설정에서 'Allow new users to sign up'이 켜져 있는지 확인 안내.
교사 전용 프로젝트면 이 설정을 꺼 기존 계정만 로그인하도록 권장.
Anonymous Sign-In도 학생의 로그인 없는 제출과 혼동하지 마
(학생 제출엔 별도 Auth 계정 없이 anon insert 정책 사용).

## 8. 보안 테스트 (직접 확인 절차 작성)
1) Ctrl+U에서 기존 비밀번호 문자열이 검색되지 않는지
2) 개발자도구 Sources에 TEACHER_PIN/ADMIN_PASSWORD 값이 없는지
3) 로그아웃 상태에서 학생 데이터 select가 거부되는지
4) 로그인 화면을 CSS/개발자도구로 강제로 숨겨도 데이터가 안 불려오는지
5) 지정 교사 계정으로 로그인하면 학생 데이터가 정상 조회되는지
6) 다른 Auth 계정으로 로그인하면 조회가 거부되는지
7) 로그인 안 한 학생은 insert가 되는지
8) 로그인 안 한 학생은 select/update/delete가 안 되는지
9) 프런트엔드에 service_role/secret 키가 없는지
10) 로그아웃 직후 화면의 학생 데이터가 지워지는지

## 9. 최종 설명 (비전공 교사용, 한글)
- 이전 방식이 왜 Ctrl+U에 취약했는지
- Supabase Auth에서는 비밀번호를 누가 검사하는지
- 프런트엔드에 실제 비밀번호가 없어지는 이유
- 로그인 화면을 숨기는 것과 데이터 권한을 막는 것의 차이
- authenticated만 허용하는 것이 왜 충분하지 않은지
- auth.uid()가 무엇인지 / RLS가 요청을 어떻게 막는지
- 공개용 키가 보여도 되는 이유 / 절대 공개 금지 키
마지막에 다음 문장을 명확히 포함해:
"변경 후에는 브라우저 소스를 전부 확인해도 교사의 실제 비밀번호가 코드에 존재하지 않습니다.
또한 지정된 교사 계정으로 로그인하지 않은 요청은 화면을 조작하거나 Supabase에 직접
select 요청을 보내더라도 데이터베이스의 RLS 정책에 의해 학생 데이터를 받을 수 없습니다."

## 10. 결과물 제시 순서
1) 수정한 파일 목록 2) 삭제한 기존 비밀번호 코드 3) 새 Auth 로그인 코드
4) SQL Editor에서 실행할 전체 SQL 5) 교사 UID 붙여 넣을 위치
6) Dashboard에서 할 설정 7) 보안 테스트 결과/방법
실제 테이블명·구조가 있으면 예시 이름 대신 실제 이름을 사용해.

📋 복사현재 웹앱의 '교사 전용 기능(예: 글 삭제, 전체 지우기, 공지·설정 저장 등)'을,
브라우저 소스를 전부 봐도 비밀번호가 드러나지 않도록
Supabase 서버가 비밀번호를 검사하는 구조로 바꿔 줘.
로그인(Auth) 계정까지는 만들지 않는 '가벼운 서버 비밀번호(PIN)' 방식이야.
먼저 전체 코드를 확인한 뒤 아래를 적용해.

## 1. 클라이언트 비밀번호 완전 제거
HTML·JS에서 코드에 직접 적힌 비밀번호 문자열, 입력값과 고정 문자열 비교,
브라우저에서 해시를 비교하는 코드, URL·localStorage 값만으로 관리자 판정하는 코드를
모두 제거해. 브라우저 코드 어디에도 실제 비밀번호가 남으면 안 돼.
(인터넷이 끊긴 로컬 단독 테스트용 임시 값은 온라인에선 안 쓰이도록 분리해도 됨.)

## 2. 비밀번호를 '서버 함수'에만 저장
Supabase에 아래 함수를 만들어. 실제 비밀번호는 이 함수 안에만 있고 앱 코드엔 없어.

create or replace function public.teacher_pin()
returns text language sql immutable security definer set search_path=public as $$
  select 'CHANGE-THIS-PIN'::text;
$$;
revoke execute on function public.teacher_pin() from anon, authenticated, public;

→ 나는 SQL Editor에서 'CHANGE-THIS-PIN'을 내 비밀번호로 바꿔 실행할 거야.
이 파일에는 실제 비번을 절대 쓰지 말고, 길게(8자 이상 영문+숫자) 쓰라고 안내해 줘.

## 3. 비번 확인 + 관리 기능을 '비번을 받는 서버 함수(RPC)'로
- 잠금 해제 확인용:
  create or replace function public.check_pin(p text)
  returns boolean language sql security definer set search_path=public as $$
    select p = public.teacher_pin();
  $$;
- 관리 작업마다 pin을 받아 검사하는 security definer 함수로 만들어. 예:
  create or replace function public.admin_delete(p text, row_id text)
  returns boolean language plpgsql security definer set search_path=public as $$
  begin
    if p <> public.teacher_pin() then return false; end if;
    delete from public.[실제_테이블명] where id = row_id;
    return true;
  end $$;
  내 앱의 실제 관리 기능(삭제/전체지우기/설정·공지 저장 등)을 파악해 각각 함수로 만들어.
- 각 함수에 grant execute ... to anon (검사는 함수 안에서 하니까 안전).

## 4. RLS로 '직접 수정·삭제'는 막기
학생 데이터 테이블 RLS 켜고: select=허용, insert=필요한 값 검증만 허용,
update/delete 정책은 아예 두지 마(=anon이 직접 수정·삭제 못 함).
관리 작업은 오직 3의 서버 함수로만 되게 해(security definer라 owner 권한으로 RLS를 통과함).
공감/좋아요처럼 값 하나만 바꾸는 것도 update 정책 대신 security definer 함수로.

## 5. 클라이언트 배선
- '교사 모드' 버튼 → 비번 입력 → check_pin(입력값) RPC로 서버 확인 →
  맞으면 관리 UI를 보여 주고, 입력한 비번을 메모리에 보관해 이후 admin 함수 호출에 넘김.
- 삭제·설정 등은 admin 함수 RPC 호출(입력 비번 전달). 실패하면 '비밀번호를 확인하세요' 안내.
- 소스 어디에도 실제 비번이 없어야 함. (교사 모드 UI를 숨기는 건 '보조'일 뿐, 진짜 차단은 서버 함수)

## 6. 정직한 한계 설명 + 테스트
- 이 방식은 '소스에 비번이 없고, 직접 삭제·설정은 서버가 비번으로 막는' 가벼운 잠금이야.
  4자리 같은 짧은 PIN은 자동 대입으로 뚫릴 수 있으니 반드시 길게 쓰라고 안내.
- 진짜 민감한 학생 데이터라면 '로그인(Auth)+RLS(auth.uid() 비교)' 방식이 더 안전하다고 함께 안내.
- 테스트 절차를 적어 줘:
  1) Ctrl+U/F12에서 비밀번호 문자열이 검색 안 되는지
  2) 틀린 비번으론 삭제·설정이 안 되는지
  3) 맞는 비번으론 삭제·설정이 되는지
  4) 비번 없이 직접 API로 delete를 보내도 RLS로 차단되는지

## 7. 결과물 제시 순서
1) 수정한 파일 목록 2) 제거한 비밀번호 코드 3) SQL 전체(teacher_pin·check_pin·admin_* 함수 + RLS)
4) 비번 바꿀 위치 5) 클라이언트 배선 6) 테스트 방법.
예시 테이블명 대신 실제 이름을 사용해.