20. User accounts data(중급) : 버블의 사용자 계정 데이터, 회원가입 구현 지식 알아보기

이 글에서는 특별한 데이터인 사용자 데이터의 의미에 대해 배우고, 앱에서 사용자 계정을 만들고 관리하는 방법을 다룹니다.

 

(1) 특별한 데이터 Type

 

:기술적으로 사용자 계정은 앱의 데이터베이스에 저장된 하나의 데이터 type일 뿐이지만 Bubble이 사용자 type을 약간 다르게 취급하는 몇 가지 이유가 있습니다.

 

• 내장된 사용자 인증 시스템은 비밀번호 해싱, 솔팅 및 암호화(hashing, salting and encryption)와 같은 강력한 보안 기능을 제공하여 사용자 데이터를 보호합니다.
• 사용자 등록, 로그인, 세션 간 사용자 기억과 같은 프로세스가 자동화됩니다.
• 이메일 주소 확인, 안전한 비밀번호 재설정, 2단계 인증, 매직 로그인 링크 및 임시 비밀번호 생성/할당과 같은 기능이 모두 안전하게 처리됩니다.
• Bubble은 로그인하지 않은 사용자가 사이트를 방문할 때마다 임시 사용자(temporary user)를 설정합니다. 해당 사용자에 저장된 데이터는 사용자가 가입을 완료하면 자동으로 전송됩니다 (예: 신규 사용자 장바구니를 저장하는 데 유용함).
• 개인정보 보호 규칙은 사용자를 다른 데이터 유형과 다르게 취급하므로 각 개별 사용자에 대해 저장된 필드를 기반으로 데이터에 대한 액세스를 제어할 수 있습니다.
• 이를 통해 세분화된 방식으로 사용자 권한을 관리하고 중요한 데이터에 대한 액세스를 제어할 수 있습니다.
• 요컨대, 사용자 계정을 관리하려면 사용자의 민감한 정보를 보호하기 위해 엄격한 보안이 필요하며 사용자 계정의 기능은 여러 플랫폼에서 상당히 균일하게 유지됩니다.
• 이것이 바로 Bubble이 애플리케이션 개발의 이러한 측면을 처리하여 앱이 최신 보안 표준으로 최신 상태가 되도록 보장하면서 개발 시간을 절약하는 이유입니다.

 

(2) 사용자 계정이란?

:우리 대부분은 살면서 수십 또는 수백 개의 사용자 계정을 가지고 있습니다.

• 전화, 이메일 계정, 소셜 미디어, 포럼, 심지어 신문에 로그인합니다. 물론 우리 모두는 그 행동이 어떤 의미인지 알고 있으므로 관점을 약간 바꿔 보겠습니다.

 

앱에 사용자 계정이 필요한 이유는 무엇입니까 ?

 

: 이 질문에 대한 첫 번째 대답은 모든 앱이 사용자 계정 필요한 것은 아니라는 것입니다.

• 사용자가 데이터베이스에서 항목을 추가하고 변경할 수 있도록 허용하더라도 사용자가 전혀 계정을 만들지 않는 매우 유용한 앱을 만드는 것은 완벽하게 가능합니다. 따라서 앱이 사용자 또는 등록된 사용자 또는 둘 모두를 가질 수 있다는 점을 먼저 알아두겠습니다.
• 이 글은 등록된 사용자, 즉 이메일과 비밀번호를 사용하거나 싱글 사인온(SSO) 서비스를 통해 가입한 사용자에 대해 중점적으로 설명합니다.

 

*싱글 사인온(SSO) : 
사용자 이름과 암호를 제공하는 대신 Google, LinkedIn 또는 Facebook과 같은 타사 계정을 사용하여 앱에 가입하고 로그인하는 것입니다. Bubble에는 이를 설정할 수 있는 여러 플러그인이 있습니다.

예시) Facebook SSO 플러그인, Twitter SSO 플러그인, LinkedIn SSO

 

 

사용자 등록은 다음과 같은 다양한 용도로 사용됩니다.

 

1) 데이터를 비공개로 유지: 사용자는 자신이 소유한 데이터 또는 선택한 다른 사용자 그룹의 데이터에만 액세스 할 수 있어야 합니다.

2) 설정 저장: 사용자는 다음에 앱을 사용할 때 여전히 그대로 있는 기본 설정 및 프로필 세부 정보를 저장할 수 있습니다.

3) 액세스 제어 : 등록된 사용자만 해당 페이지에 액세스 할 수 있습니다.

4) 역할 및 권한 할당 : 등록된 사용자가 있으면 각 사용자를 식별하고 액세스 권한이 있는 항목을 할당할 수 있습니다.

5) 개인화: 소셜 미디어 및 전자 상거래 상점과 같은 일부 응용 프로그램은 각 사용자에 대해 개인화된 콘텐츠 스트림을 제공합니다.

6) 팀 구성 : 일부 앱은 사람들이 데이터를 공유하고 협업할 수 있도록 팀을 구성해야 합니다. 무엇에 액세스할 수 있는지 제어하려면 그들이 누구인지 알아야 합니다.

7) 결제 처리 : 결제를 처리하고 주문 및 결제 내역을 유지하기 위해 일반적으로 등록된 사용자에게 연결하려고 합니다.

커뮤니케이션 : 사용자가 누구인지 알면 앱 또는 이메일과 같은 외부 채널을 통해 사용자와 커뮤니케이션할 수 있습니다.

 

• 위와 같이 사용자가 가입하기를 원하는 이유에는 여러 가지가 있으며 이는 보안 및 개인 정보 보호와만 관련된 것만이 아닙니다.
• 다른 데이터 유형과 마찬가지로 필요한 만큼 다양한 필드를 추가할 수 있지만 사용자 유형에는 계정을 처리하기 위한 몇 가지 추가 필드도 함께 제공됩니다.
• 이러한 필드는 변경하거나 삭제할 수 없으며 모든 Bubble 애플리케이션에서 동일합니다.

 

(3) 기본 제공 필드

모든 데이터 유형에 대한 4개의 기본 제공 필드 외에도 사용자에게는 다음과 같은 3개의 추가 필드가 제공됩니다.

 

1. 기본 제공 필드 4개

:모든 데이터 유형에는 즉시 사용할 수 있는 네 가지 필드가 있습니다.

• Unique ID : 고유 ID
• Created Date : 만든 날짜
• Modified Date : 수정된 날짜
• Slug : 하나의 데이터 레코드를 위한 url 이름

 

2. 추가 필드 3개

• 이메일
• 암호(보이지 않음)
• 이메일 확인됨(보이지 않음)

 

3. 추가 필드의 속성

1) 이메일 : Email

• 이메일 필드는 등록된 사용자의 경우 비워둘 수 없으며 유효한 이메일 주소로 형식을 지정해야 합니다.
• 앱의 모든 사용자는 고유한 이메일 주소를 가지고 있어야 합니다.

 

2) 암호(데이터베이스에 보이지 않음) : Password

• 비밀번호 필드는 앱 개발자에게도 보이지 않는다는 점에서 다른 모든 필드와 다릅니다.
• 암호는 산업 표준 관행에 따라 안전하게 유지됩니다.

 

*암호를 안전하게 유지하는 방법

• Bubble은 단방향 해싱 및 솔팅(hashing, salting)을 사용하여 사용자 비밀번호의 안전을 보장합니다.
• 이 방법을 사용하면 누군가가 Bubble 데이터베이스에 대한 액세스 권한을 얻더라도 암호(password)가 원래 형식으로 되돌릴 수 없는 해시값으로 변환됩니다.
• 암호는 로그인 시 사용자가 입력한 암호를 가져와 해시하고 데이터베이스에 저장된 해시된 암호와 비교하여 확인합니다.
• Bubble은 실제로 원래 비밀번호가 무엇인지 알지 못한 채 두 해시 사이의 일치 항목에만 집중한다는 점에 유의해야 합니다. 따라서 Bubble 본사도 사용자의 원래 비밀번호에 액세스할 수 없습니다.
• 이 단방향 해싱 및 솔팅 방법은 비밀번호 저장을 위한 모범 사례로 널리 알려져 있습니다.

 

3) 이메일 확인됨(데이터베이스에 보이지 않음) : Email Confirmed

• 확인된 이메일은 또 다른 보이지 않는 필드입니다.
• 사용자가 확인 이메일 보내기 작업을 사용하여 이메일을 확인했는지 여부를 반영하는 예/아니오 값을 보유합니다.
• 개발자나 사용자는 이 필드를 직접 변경할 수 없습니다.
• 이 값을 변경하려면 사용자가 위에서 설명한 ‘확인 이메일 받아서 확인’하는 작업을 수행해야 합니다.

 

(4) 가입

사용자를 등록하려면 해당 사용자가 앱에서 고유한 유효 이메일 주소와 비밀번호라는 두 가지 텍스트 문자열을 제공해야 합니다.

워크플로우 가입 action 화면

 

• 이메일과 비밀번호는 일반적으로 입력 요소(input element)를 통해 제공됩니다.
• 위의 예시에는 새 사용자가 암호를 입력하는 두 개의 입력 요소(input element)가 있습니다.
• 하나는 암호를 설정하고 두 번째는 철자가 틀리지 않았는지 확인하는 것입니다.
• 앱의 사용자는 고유한 이메일 주소를 가지고 있어야 합니다.

 

*정보는 암호화된 상태로 Bubble의 서버로 전송되며 암호는 해시(hashing)되고 솔팅(salting) 처리됩니다. 즉, Bubble 팀을 포함하여 아무도 읽을 수 없는 암호가 되는 것으로 이것은 보안 모범 사례로 꼽히고 있습니다.

 

• 입력 요소는 특정 방식(예: 암호 입력 필드의 문자를 별표로 대체)으로 입력 형식을 지정하고 특정 형식(예: 유효한 이메일 주소)을 예측하도록 설정할 수 있습니다.
• 가입 및 로그인 양식을 설정할 때 이 두 기능을 모두 사용하는 것이 좋습니다.
• 이 작업이 트리거 되는 즉시 계정이 생성되고 사용자는 해당 시점부터 로그인됩니다.

 

*로그인 세션은 12개월 동안 또는 사용자가 로그아웃하거나 브라우저에서 쿠키를 삭제할 때까지 지속됩니다.

 

(5) 로그인

: 로그인 작업은 이메일과 비밀번호의 두 가지 입력이 필요하다는 점에서 가입 작업과 매우 유사합니다. Bubble은 이 데이터를 암호화된 상태로 서버로 보내 자격 증명을 확인합니다. 둘 다 맞으면 사용자가 로그인한 것입니다.

 

*SSA 로그인: SSA 공급자는 사용자의 로그인을 허용하는 데 사용할 수 있는 타사 서비스입니다.

 

예를 들면 다음과 같습니다.

 

1. OAuth - 타사 서비스로 가입 및 로그인

:사용자를 인증하는 가장 일반적인 방법은 비밀번호나 이메일을 입력하라는 메시지를 표시하는 것입니다. 그러나 때로는 해당 서비스의 자격 증명을 사용하여 사용자를 인증하기 위해 Facebook, LinkedIn 또는 Gmail과 같은 일부 외부를 사용하게 됩니다.

 

여기에는 몇 가지 장점이 있습니다.

• 이를 통해 사용자는 더 빠르게 인증할 수 있으며 다른 암호를 기억할 필요가 없습니다.
• 가입 프로세스는 일반적으로 몇 번의 빠른 클릭으로 완료됩니다. (외부 서비스 및 사용자가 이미 로그인했는지 여부에 따라 다름)
• 일부 서비스는 이메일, 프로필 사진, 소셜 미디어 게시물과 같은 사용자 작성을 대신하여 일부 데이터를 가져올 수 있습니다.

아래에서는 Facebook을 예로 들어 보겠습니다. (앱에서 'Facebook으로 로그인' 버튼을 제공합니다.)

 

2. 페이스북으로 가입하기

: 아래 가이드는 Facebook 로그인이 전반적으로 작동하는 방식을 설명합니다.

 

• Bubble에서 이러한 흐름을 설정할 때 앱이 작동하기 위해 사용자로부터 원하는 인증 수준을 정의해야 합니다.
• 기본적으로 대부분의 서비스는 사용자가 자격 증명을 사용하여 타사 애플리케이션에 가입할 때만 공개 프로필과 이메일을 노출하지만 더 많은 권한을 요청할 수 있습니다 (예: 담벼락에 게시).
• 필요한 경우에만 권한을 요청하는 것이 사용자 및 보안 관점에서 가장 좋은 방법이며 긴 권한 목록을 요청하면 등록하는 사용자가 줄어들 수 있다는 점(사용자 이탈)을 명심해야 합니다.
• 사용자가 Bubble에서 소셜 네트워크(Facebook)로 가입하면 이메일과 비밀번호를 사용하는 기존 가입 흐름과 유사하게 데이터베이스에 새 사용자가 생성됩니다.
• 가장 큰 차이점은 사용자가 로그아웃한 후 다시 로그인 시 비밀번호를 입력하는 방식이 아니라(비밀번호를 정의하지 않았기 때문에) Facebook으로 로그인하는 방식이라는 점입니다.
• 사용자가 Facebook으로 로그인하고 앱이 동일한 브라우저에서 Facebook 로그인을 사용하는 경우 사용자는 자동으로 해당 Facebook 사용자로 로그인됩니다.

 

3. 기존 로그인과 소셜 로그인 혼합

: Bubble의 사용자는 기존 로그인과 소셜 로그인을 동시에 사용할 수 있습니다.

여기에 몇 가지 경우가 있습니다.

 

1) 사용자가 현재 이메일과 비밀번호로 로그인하고 인증절차를 진행할 경우

• 링크를 통해 인증 공급자(Oauth, 예: Facebook, Google 등)와 계정을 연결하라는 메시지를 표시할 수 있습니다.
• 사용자가 이러한 절차를 거치면 새 사용자가 생성되지 않고 현재 로그인한 사용자에게 인증 자격 증명이 추가됩니다.
• 이 절차가 완료되면 사용자는 자신의 이메일/비밀번호 또는 인증 절차를 통해 로그인할 수 있습니다.
• 만약 외부 서비스에서 제공한 이메일과 같은 이메일을 사용하는 다른 사용자가 데이터베이스에 있으면 작업이 실패하고 사용자에게 메시지가 표시됩니다.

 

2) 사용자가 현재 로그인하지 않고 인증 절차를 진행할 경우

• 동일한 이메일(Facebook에 등록된 이메일)을 가진 사용자가 앱의 데이터베이스에 이미 존재하는 경우를 제외하고 새 사용자가 생성됩니다.
• 같은 이메일을 가진 사용자가 존재할 경우 인증 절차가 실패하고 사용자에게 메시지가 표시됩니다.

 

3) 사용자가 외부 인증 서비스로 먼저 가입하고 자신의 계정에 암호를 추가하려는 경우

• '사용자 암호 재설정' 작업을 통해 이를 수행할 수 있습니다.
• 이렇게 하면 개발자는 Oauth 자격 증명으로만 인증한 사용자를 효과적으로 수정하고, 사용자는 자신의 계정에 대한 이메일 및 암호 값을 변경 사용할 수 있습니다.

 

(6) 임시 사용자 : Temporary users

: 사용자가 앱에 가입하는 순간은 이메일 주소와 데이터베이스의 영구적으로 사용을 할당하는 것입니다.

• 대부분의 경우 사용자가 나중에 계정에 액세스하는 데 사용할 암호를 제공하는 경우이기도 합니다.
• 데이터 관점에서 Bubble은 이전 시점에서 실제로 사용자가 누구인지 추적합니다.(한 가지 예외 있음: *설정에서 새 사용자에 대한 쿠키 설정 안 함 ).
• 로그인하지 않은 새 사용자가 애플리케이션을 방문할 때마다 Bubble은 브라우저에 쿠키를 저장하고 임시 사용자를 만듭니다.

 

*이 버블 기능은 앱이 쿠키를 허용하는 한 현재 사용자 데이터 소스가 빈 값을 반환하지 않음을 의미합니다. 사용자가 실제로 로그인했는지 확인하려면 현재 사용자 *로그인 연산자를 사용할 수 있습니다.

 

 

*로그인 연산자: is logged in

 

• 이를 통해 세션 중에 사용자가 누구인지 "기억"할 수 있으며 현재 사용자에 저장된 데이터 액세스에 의존하는 애플리케이션 logic을 설정할 수 있습니다.

 

• 이는 다양한 시나리오에서 유용합니다.
  • 기본 설정 및 설정 저장
  • 장바구니처럼 임시 데이터 저장
  • 사용자 경험 개인화

 

가입 절차가 완료되면 Bubble은 임시 데이터를 새로 생성된 사용자에게 자동으로 전송합니다.

*임시 사용자에 저장된 데이터는 사용자가 가입할 때 자동으로 전송되지만 로그인할 때는 전송되지 않습니다.

 

(7) 사용자 계정 FAQ

1. 암호를 볼 수 없는 경우 사용자가 로그인하도록 어떻게 도울 수 있습니까?

• 앱 개발자를 포함하여 그 누구도 사용자 비밀번호에 액세스할 수 없도록 하는 것이 기본적인 보안 모범 사례로 널리 알려져 있습니다.
• 사용자가 비밀번호를 잊어버린 경우 로그인을 돕는 가장 좋은 방법은 비밀번호를 재설정하거나 임시 비밀번호를 생성하는 것입니다.

 

2. 여러 장치의 세션에서 사용자를 로그아웃할 수 있습니까?

• 예, 다른 사용자의 세션에서 로그아웃 작업을 사용할 수 있습니다.
• 이 작업은 작업을 실행 중인 장치를 제외한 모든 장치에서 사용자를 로그아웃합니다.
• 해당 세션도 로그아웃하려면 사용자 로그아웃 작업을 사용해야 합니다.

 

3. 사용자는 얼마 동안 로그인 상태를 유지합니까?

• 사용자 로그인 작업에서 설정한 설정에 따라 다릅니다.
• 임시 사용자 (가입하지 않았지만 쿠키가 있는 사용자)는 72시간 동안 동일한 장치에서 활성상태로 유지됩니다.
• 사용자 로그인 유지 확인란을 선택하지 않은 경우 사용자는 24시간 후에 로그아웃됩니다.
• 체크박스를 선택하면 사용자는 12개월 후 로그아웃됩니다.
• 사용자가 로그아웃되는 또 다른 경우가 있습니다.
• 사용자 로그아웃 작업이 트리거 된 경우
• 다른 기기에서 다른 사용자 세션 로그아웃이 실행된 경우
• 사용자가 브라우저의 쿠키를 지우는 경우

 

4.’현재 사용자 데이터의 setting, action 변경’(the Make changes to action and setting the data source to current user) 과 ‘현재 사용자의 변경 action’을 사용하는 것(the Make changes to current user action) 사이에 차이가 있습니까? (the Make changes to 라는 명령어가 있음)

• 아니요, 둘 사이에는 차이가 없습니다. 둘 다 사용자의 사용자 정의 필드를 변경할 수 있게 해 줍니다.

 

5. 현재 사용자 변경 작업에서 사용자의 이메일 필드를 선택할 수 없는 이유는 무엇입니까?

• 암호화 필드는 사용자 자격 증명(the user's credentials)의 일부로 간주된다는 점에서 특별합니다. 그렇기 때문에 Update the user's credentials 라는 업데이트 전용 작업이 있습니다.
• 보안상의 이유로 이 작업을 수행하려면 사용자가 암호를 다시 입력해야 합니다. (입력 요소 :Input element 에서 사용자의 암호를 인증하는 설정 해야 함을 의미)

 

[ 참고 : 버블의 쿠키 설정에 대해 알아보기 ]

75. Bubble의 쿠키 설정 (중급) : Cookies set by Bubble, 기본 쿠키 설정, 쿠키 설정 끄기 > 바로가기