NgSysV.A 심각한 Svelte InfoSys: Firebase D/B 규칙 및 로그인

이 게시물 시리즈의 색인은 NgateSystems.com에 있습니다. 거기에서 매우 유용한 키워드 검색 기능도 찾을 수 있습니다.

최종 검토일: 2024년 11월

1. 소개

2.3 이후의 도움으로 첫 번째 Firestore 데이터베이스를 생성할 때 "프로덕션" 규칙을 적용할지 아니면 "테스트" 규칙을 적용할지 묻는 메시지를 받았다는 것을 기억하실 것입니다. 당시의 제안은 "테스트" 규칙을 선택해야 한다는 것이었습니다. 이 시점에서 Firebase 콘솔의 Firestore 페이지에 있는 "규칙" 탭을 사용했다면 규칙이 다음과 같이 설정되었음을 알 수 있습니다.

match /{document=**} {
  allow read, write: if request.time < timestamp.date(2024, 10, 31);
}

여기서 Google은 타임스탬프를 사용하여 데이터베이스를 만든 날로부터 30일 동안 데이터베이스에 대한 읽기 및 쓰기 액세스를 허용하는 기본 규칙을 만들었습니다. 그것은 지금 당신이 원하는 것이 아닐 것입니다. 어쨌든 구글은 당신에게 그것을 바꾸라고 잔소리할 것입니다. 이제 Firestore 규칙과 이를 사용하여 데이터베이스를 안전하게 만드는 방법에 대해 자세히 알아볼 차례입니다.

데이터베이스 규칙

Firestore '규칙'을 사용하면 데이터베이스 호출이 이루어질 때마다 Firestore '규칙 핸들러'에 전달되는 Firebase 요청 객체를 참조하여 데이터베이스 컬렉션에 대한 읽기 및 쓰기 액세스를 제한할 수 있습니다. 이 객체에는 무엇보다도 요청한 사용자의 세부 정보, 수행 중인 작업 유형 및 현재 시간이 포함됩니다. 전체 속성 목록을 보려면 chatGPT가 이를 제공할 것입니다.

Firestore 규칙 구문에 대한 전체 설명을 얻으려면 Firestore 규칙 시작하기에서 Google 자체 문서를 참조하는 것이 가장 좋습니다. 현재 목적을 위해 이 게시물 시리즈에서 생성한 기본 데이터베이스에 대한 즉각적인 요구 사항에 집중하겠습니다.

실제 데이터베이스 규칙을 보려면 Firebase 콘솔의 Firestore 페이지에 있는 '규칙' 탭을 사용하여 규칙을 다음과 같이 변경해 보세요.

    match /{document=**} {
      allow read: if true;
      allow write: if request.time < timestamp.date(2000, 01, 01);
    }

이 규칙은 시간이 2000년 1월 1일 이전인 경우에만 데이터베이스의 문서에 대한 쓰기 액세스를 허용합니다. 따라서 현재 타임머신에서 실행 중이 아닌 이상 새 문서를 만들 수 없습니다. 문서.

새 규칙을 활성화하려면 '게시' 버튼을 클릭하고(게시가 적용되는 데 시간이 걸릴 수 있다는 메시지는 무시해도 됩니다. 실제로는 지연 시간이 아주 적은 것 같습니다) 웹앱이 어떻게 반응하는지 확인하세요.

개발 서버를 시작하고 http://localhost:5173에서 웹앱을 실행하세요. 새 제품을 추가하려고 할 때 "500: 내부 오류" 페이지가 표시되더라도 너무 놀라실 필요는 없습니다. 원인을 조사하기 위해 터미널 세션으로 이동하면 다음 메시지가 표시됩니다.

match /{document=**} {
  allow read, write: if request.time < timestamp.date(2024, 10, 31);
}

이제 Firestore 규칙의 작동 방식을 이해했으므로 Post 3.1에서 만든 제품 디스플레이 및 제품 유지 관리 페이지에서 이를 어떻게 사용할 수 있는지 생각해 볼 수 있습니다.

기억하시겠지만 이들은 다음과 같은 두 가지 경로를 제공했습니다.

• 사용자가 제품 컬렉션의 모든 문서를 읽을 수 있도록 하는 localhost:5173/products-display의 "products-display" 경로 및
• 사용자가 컬렉션에 새 문서를 작성할 수 있도록 하는 localhost:5173/products-maintenance의 "제품 유지 관리" 경로입니다.

"products-display" 경로를 사용하여 누구나 제품 문서를 읽을 수 있도록 기꺼이 허용하지만 승인된 개인만 읽기를 원할 것이라고 가정합니다. "제품 유지 관리" 경로를 사용하여 새 제품을 추가할 수 있습니다.

개인은 웹앱에 "로그인"하는 데 사용할 수 있는 "사용자 ID/비밀번호" 조합을 발급하여 인증됩니다. 이 절차는 사용자가 데이터베이스에 액세스하려고 할 때 Firestore 규칙 처리에 전달되는 Firebase 요청 객체의 일부가 되는 사용자의 클라이언트 기기에 지속적인 '인증' 상태를 생성합니다.

그런 다음 Firestore 규칙을 다음과 같이 설정하면:

    match /{document=**} {
      allow read: if true;
      allow write: if request.time < timestamp.date(2000, 01, 01);
    }

"로그인"한 사용자만 "제품" 페이지에 글을 쓸 수 있습니다.

이제 알아야 할 것은 인증 상태를 생성하기 위해 "로그인" 페이지를 작성하는 방법뿐입니다. 꼭 읽어주세요!

2. 파이어베이스 로그인

로그인 화면에서 잠재 시스템 사용자는 개인 식별자(일반적으로 이메일 주소)와 관련 비밀번호를 제공하라는 요청을 받습니다.

그런 다음 시스템은 알려진 자격 증명의 보안 목록과 비교하여 사용자의 식별자와 비밀번호를 확인합니다. Firebase에서는 프로젝트의 Firebase 콘솔에 있는 '빌드 -> 인증 -> 사용자' 탭에서 이 목록을 찾을 수 있습니다. 이것 좀 보세요. 테스트 이메일 주소와 비밀번호를 등록해 보세요("프로그래밍 방식" 등록도 가능하지만 여기서는 다루지 않습니다). Firebase가 등록에 할당하는 "사용자 UID 필드"를 참고하세요. 이는 이메일 주소의 고유하고 암호화된 버전입니다. 곧 살펴보겠지만 이는 Firebase 보안 메커니즘의 중요한 요소를 형성합니다. 또한 화면에는 계정 삭제 및 비밀번호 변경 기능이 제공됩니다.

여기 있는 동안 '인증' 화면에서 '로그인 방법' 탭을 확인하세요. 이메일/비밀번호 조합 또는 Google 계정이 제공됩니다. 이 단계에서는 이메일/비밀번호 옵션만 활성화하는 것이 좋습니다.

이제 로그인 화면을 만들어 보세요. 아래에 표시된 샘플 코드는 놀라울 정도로 간단합니다(그리고 대부분은 스타일 지정입니다!).

[FirebaseError: Missing or insufficient permissions.] {
  code: 'permission-denied',
  customData: undefined,
  toString: [Function (anonymous)]
}

로그인 및 로그아웃 스크립트를 위한 새 경로 폴더와 page.svelte 파일을 만듭니다. 하지만 아직은 실행하지 마십시오. 몇 가지 추가 정보를 더 알려드릴 필요가 있기 때문입니다.

이제 이러한 파일은 중앙 src/lib/utilities/firebase-client.js 파일에서 인증 변수를 가져옵니다. 이 내부에서 웹 앱은 Firebase가 인증 객체를 생성할 권한이 있음을 확인하기 위해 firebase-config 키를 제공합니다. 이를 수행하는 src/lib/utilities/firebase-client.js의 업데이트된 버전은 다음과 같습니다.

match /{document=**} {
  allow read, write: if request.time < timestamp.date(2024, 10, 31);
}

여기서 내보낸 app, auth 및 db 변수는 웹앱에서 광범위하게 필요하므로 중앙 위치에서 생성하면 많은 코드가 절약됩니다.

그런데 여기서 "블링" 몇 조각에 대해서는 설명이 필요합니다.

먼저, 저는 더 이상 코드에서 apiKey와 같은 firebaseConfig 속성을 직접 코딩하지 않고 프로젝트의 .env 파일(파일 또는 "."이 있는 폴더는 "시스템" 데이터임을 나타냅니다. 여기 있습니다:

    match /{document=**} {
      allow read: if true;
      allow write: if request.time < timestamp.date(2000, 01, 01);
    }

.env 파일의 핵심은 firebaseConfig 키를 애플리케이션 코드가 포함되지 않은 파일에 저장하는 것입니다. 이렇게 하면 보안을 훨씬 쉽게 관리할 수 있습니다. 하지만 지금은 더 중요한 일에 집중할 수 있도록 이 내용을 한쪽으로 치워 두겠습니다. 모든 내용을 설명할 수 있도록 이 게시물 끝에 메모를 추가했습니다.

당신을 당황하게 할 두 번째 기능은 const app = !getApps().length ? 초기화App(firebaseConfig) : getApp(); 선. 이것은 Javascript "삼항" 문의 예입니다(이전에 만나본 적이 없다면 chatGPT에서 작동 방식을 설명하세요). 그 효과는 다음과 같습니다.

• 현재 Firebase 환경에 앱이 없는 경우에만 Firebase 앱을 초기화하세요. 웹앱은 사용자 세션 중에 firebase-client.js를 자주 참조하며 앱이 이미 존재하는 경우 초기화App()이 실패합니다
• 그렇지 않으면 기존 앱을 검색하세요.

이제 주류로 돌아가서 이 모든 것의 효과는 로그인이 성공하면 Firebase가 인증된 사용자에 대한 "인증" 객체를 생성하고 이를 브라우저 환경에서 안전하게 제거한다는 것입니다. 따라서 Firebase는 여기에서 생성된 인증 토큰을 FireStore 데이터베이스 서비스 요청에 전달된 모든 요청 객체에 자동으로 추가할 수 있습니다. 토큰 정보에는 앞서 Firebase 인증 탭에서 본 '사용자 uID' 식별자와 같은 속성이 포함됩니다. 결과적으로 Firestore는 쓰기 허용: if request.auth != null과 같은 규칙을 적용하는 방법을 결정할 수 있습니다.

이것은 클라이언트 측 Firestore 활동이 시계처럼 작동한다는 것을 의미합니다. 일단 로그인하면 Firestore 규칙이 모든 데이터베이스 보안 문제를 처리합니다.

하지만 걸림돌이 있습니다. 사실 엄청난 걸림돌입니다. Firebase가 브라우저 환경에 삽입한 '인증' 개체는 Inventory-maintenance/page.server.js와 같은 서버 측 페이지에서 사용할 수 없습니다.

이것을 쉽게 시연할 수 있습니다.

1. 누구나 제품 컬렉션의 모든 내용을 읽을 수 있지만 인증된 사람만 문서를 작성할 수 있도록 보장하는 새로운 Firestore 규칙을 게시합니다
   

   match /{document=**} {
     allow read, write: if request.time < timestamp.date(2024, 10, 31);
   }
   

2. /login 경로를 사용하여 로그인하면 "Google에 로그인되어 있습니다"라는 알림을 받습니다.

3. /products-display 페이지를 실행하세요. Firestore 규칙에 따라 누구나 모든 내용을 읽을 수 있기 때문입니다. 따라서 페이지에는 이전과 동일하게 현재 등록된 제품 목록이 표시됩니다.

4. 제품 유지 관리 페이지에서 새 제품을 추가해 보세요. 아! 오류!
   

    match /{document=**} {
      allow read: if true;
      allow write: if request.time < timestamp.date(2000, 01, 01);
    }

여기서 발생한 문제는 브라우저의 '분산형' 인증 변수와 나머지 상위 Firebase 세션 정보를 서버의 Firestore에서 사용할 수 없다는 것입니다. 결과적으로 request.auth가 정의되지 않았으므로 Firestore 규칙이 실패합니다.

Google은 클라이언트 측의 삶을 즐겁게 만들어주는 뛰어난 세션 관리 기능의 서버 측 버전을 Firebase에 제공하는 것을 거부했다는 입장입니다. 현재 귀하의 코드는 Firestore Client API를 사용하고 있습니다. Firestore 데이터베이스가 Firebase 인증 세션 변수를 참조하는 컬렉션에 '규칙'을 설정한 서버에서는 클라이언트 API가 아닌 Firestore Admin API를 사용해야 합니다. Admin API 호출은 Firestore 규칙을 확인하지 않으므로 인증이 정의되지 않은 경우에도 실패하지 않습니다. 하지만 Admin API를 사용하면 다음과 같은 여러 가지 결과가 발생합니다.

• Admin API는 다양한 '호출 서명'을 사용합니다. 서버 측에서 데이터베이스 읽기/쓰기 작업을 수행하는 데 사용하는 관리 API 함수의 순서는 클라이언트 버전과 대체로 유사하지만 다른 구문을 사용합니다.
• Admin API를 사용하려면 직접 작성한 코드를 사용하여 필요한 사용자 데이터를 얻어야 합니다. uID 및 userName 등을 제공하기 위해 귀중한 auth.currentUser 객체를 편리하게 제공했던 클라이언트 측 Firebase 세션을 더 이상 서버 측에서 사용할 수 없습니다. 교체품을 제공하려면 직접 준비해야 합니다.

신음소리. 대안이 있나요? 다음 두 게시물은 다음과 같습니다.

1. 웹 앱의 '규칙 친화적' 버전을 개발하여 문제를 피할 수 있는 방법. 그 결과 성능 저하(서버 측 코드가 더 빠르게 실행되기 때문에), 보안 감소(클라이언트 측 양식 유효성 검사가 안전하지 않기 때문에) 및 SEO 전망 감소(웹 스파이더가 클라이언트 측 코드 인덱싱에 대한 열정이 감소했기 때문에)
2. 또는 웹앱의 전체 "클라이언트-서버" 버전을 놓고 경쟁하고 개발하는 방법. 이는 최고의 성능, 보안 및 SEO를 제공하지만 Firebase 사용자 세션 배열의 손실로 인해 남겨진 기능 격차를 메우기 위해 또 다른 기술의 물결을 협상해야 합니다

3. 결론

불행한 결말로 힘든 여정을 마무리했습니다. 하지만 계속해서 읽을 수 있는 에너지가 있기를 바랍니다.

개발자의 관점에서 볼 때 규칙 친화적 코드는 브라우저의 Inspector 도구를 사용하여 완전히 디버깅할 수 있기 때문에 완벽한 즐거움을 선사할 것입니다. 앞서 언급한 바와 같이 제한 사항이 있기는 하지만 많은 간단한 응용 프로그램에는 완벽하게 만족스러울 수 있습니다.

클라이언트-서버 버전은 몇 가지 새로운 과제를 제시하지만 주류 개발 방식에 대한 귀중한 경험을 제공하고 정말 놀라운 성능을 제공할 것입니다.

추신 - 이 ".env" 비즈니스는 무엇을 의미합니까?

이상하게 보일 수도 있지만 이 모든 것은 Microsoft의 "Github" 버전 제어 소프트웨어에서 시작됩니다. 이는 개인 웹 기반 저장소에 소스 복사본을 복사할 수 있는 무료 웹앱입니다. 이는 업계 표준이 되었으며 Git 및 Github에 대한 간단한 소개에서 이에 대해 알아볼 수 있습니다.

주요 목적은 동일한 프로젝트에서 동시에 작업하는 개발자 팀의 활동을 통합하는 것입니다. 하지만 귀하 이 기능을 사용하는 데 관심이 있을 수도 있습니다. 개인 프로젝트를 개발하고 지속적으로 개선하는 동안 코드의 "체크포인트" 스냅샷을 안전한 곳에 배치하고 싶을 때가 있기 때문입니다. .

문제는 소스 코드에 포함된 민감한 키가 실수로 Git 저장소에 저장되기가 너무 쉽다는 것입니다. 저장소를 "비공개"로 표시할 수 있지만 보안은 보장되지 않습니다.

대답 중 하나는 프로젝트 키가 코드 파일과 별도로 보관되도록 정리하는 것입니다. 이렇게 하면 Git에 복사할 필요가 없습니다. libutilitiesfirebase-client.js 파일에 Firebase 키를 배치하면 키가 더 이상 여러 page.server.js 파일에 코딩되지 않는다는 의미이므로 도움이 되었습니다. 하지만 중앙 firebase-client.js에는 저장소에 저장하고 싶은 코드가 여전히 남아 있습니다. env 파일을 사용하면 최종적으로 키에서 코드를 분리할 수 있습니다. .env 키는 프로젝트에 남아 있지만 이 파일을 더 이상 코드 저장소에 복사할 필요가 없습니다. 따라서 제외할 파일을 Git에 알려주는 .gitignore 파일에 추가할 수 있습니다.

Svelte가 프로젝트를 초기화할 때 .gitignore 파일을 생성했으며 이 파일에는 이미 소스 코드 체크포인트에 없는 Vite 시스템 폴더의 세부 정보가 포함되어 있음을 알 수 있습니다. ".env" 파일(및 해당 파일의 모든 편집 기록)이 모든 Git 커밋에서 제외되도록 하려면 다음 항목을 추가하세요.

match /{document=**} {
  allow read, write: if request.time < timestamp.date(2024, 10, 31);
}

이 작업을 완료하면 VSCode 작업 공간 디렉터리의 /.env 줄이 "회색으로 표시"됩니다. 이는 이 파일이 Git 커밋으로 인해 웹에 공개되지 않는다는 것을 시각적으로 보장합니다.

위 내용은 NgSysV.A 심각한 Svelte InfoSys: Firebase D/B 규칙 및 로그인의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!