계정 연결 빠른 시작

이 계정 연결 빠른 시작에서는 여러 기기 및 로그인 메커니즘에 계정을 바인딩하는 방법을 보여줍니다. 단일 PlayFab 계정은 여러 기기 및 로그인 자격 증명으로 액세스할 수 있습니다. 로그인 기본 사항 및 모범 사례 튜토리얼에서 논의한 것처럼 사용자 인증에는 두 가지 형태가 있습니다.

1. 익명
2. 복구 가능

​

기존 익명 계정에 복구 가능 로그인 추가하기

첫 로그인이 익명 로그인인 경우가 매우 흔합니다. 이렇게 하면 플레이어가 마찰 없이 게임에 진입할 수 있습니다. 그러나 플레이어가 게임에 몰입하게 되면 기기 오작동이나 기타 문제 발생 시 계정을 복구 가능하게 만드는 복구 가능한 로그인 방법을 추가하도록 안내해야 합니다. 이 섹션에서는 익명 계정에 복구 가능한 로그인 메커니즘을 추가하는 방법을 다룹니다. 이 튜토리얼의 초점은 위 이미지의 하단, 즉 AddUsernamePassword, LinkWithFacebook, LinkWithGoogle 셀에 있습니다. 이는 복구 가능한 로그인 메커니즘에 대해 사용할 수 있는 더 큰 옵션 집합 중 몇 가지를 나타냅니다.

• AddUsernamePassword는 LoginWithPlayFab 및 LoginWithEmailAddress 중 하나 또는 둘 다를 활성화하는 데 사용됩니다. 이러한 옵션은 사용자 이름/이메일/비밀번호 자격 증명을 PlayFab에 직접 저장합니다. 플레이어가 계정을 복구하려면 게임, 웹사이트 또는 고객 서비스에서 다음을 트리거할 수 있습니다.
  • 해당 이메일 주소에 대한 SendAccountRecoveryEmail. 플레이어가 가짜 이메일 주소를 입력한 경우에도 PlayFab Game Manager를 사용하여 플레이어의 이메일 주소를 업데이트할 수 있지만, 고객 서비스 담당자가 일반적인 사회 공학적 속임수에 주의하도록 교육받아 실제 계정 소유자의 이메일 주소만 업데이트하도록 하는 것이 중요합니다.

각 타사 복구 가능 로그인 메커니즘은 적절한 SDK 또는 타사 API 호출을 통해 사용자가 로그인하도록 안내하는 것을 포함합니다. 해당 계정을 PlayFab에 연결하는 것은 일반적으로 동일한 패턴을 따릅니다.

1. 먼저 사용자에게 해당 서비스에 로그인하도록 안내합니다(자세한 내용은 로그인 기본 사항 및 모범 사례 참조).
2. 로그인하면 해당 서비스는 어떤 종류의 토큰을 제공하며, 이를 PlayFab에 전달할 수 있습니다.
3. 이를 통해 PlayFab는 사용자의 해당 서비스 자격 증명을 알지 못한 채 안전하게 해당 계정에 연결할 수 있습니다.

​

모범 사례

익명 로그인을 사용하여 마찰 없이 신규 플레이어를 생성하세요. 튜토리얼 단계 이후에는 원하는 복구 가능 자격 증명을 계정에 연결하도록 플레이어를 부드럽게 유도하세요. 타사 인증 시스템을 사용하는 경우 해당 서비스에서 (API 호출 또는 SDK 함수를 통해) 적절한 토큰을 검색한 다음, 적절한 PlayFab API를 호출하여 해당 서비스의 플레이어 계정을 PlayFab 계정에 연결합니다: LinkFacebookAccount, LinkGameCenterAccount, LinkGoogleAccount, LinkKongregate, LinkSteamAccount, LinkTwitch, LinkWindowsHello.

​

모범 사례

• 사용자 개인 정보 보호를 위해 사용자 자격 증명을 저장하거나 보관하지 마세요(이것은 COPPA 준수를 위해 필요한 여러 단계 중 하나이기도 합니다. 타이틀에 요구되는 경우 준수를 확인하기 위해 반드시 법률 자문에 문의하세요).
• PlayFab 자격 증명을 사용하거나 타사 API를 직접 호출하는 경우 가능한 한 빨리 메모리에서 로그인 정보를 지워야 합니다. 일반적으로 타사 SDK가 이를 대신 처리해 줍니다.
• 필요 이상으로 식별 가능하거나 보안이 필요한 정보를 메모리에 보관하지 말고, 파일이나 원격 위치에 저장하지 마세요. PlayFab API는 필요한 최소 정보만 활용하도록 설계되었습니다.

​

기존 복구 가능 계정에 새 기기 추가하기

PlayFab는 여러 로그인 및 기기가 동일한 계정에 액세스하도록 허용합니다. 올바르게 설정되면 플레이어는 모든 기기에서 게임을 플레이하고, 그 기기를 내려놓고, 새로운 기기(다른 유형, 브랜드, 플랫폼 또는 OS라도)를 집어 들고, 모든 데이터가 그대로 유지된 상태로 동일한 게임을 재개할 수 있습니다.

​

요구 사항

플레이어는 두 개의 기기를 소유해야 합니다.

• Device1 - 계정과 복구 가능 자격 증명이 이미 올바르게 설정된 기기. 두 번째 기기가 계정에 바인딩되지 않은 상태인 것이 이상적입니다. 이 과정은 두 번째 기기의 ID만이 로그인 메커니즘으로 있는 계정을 고아 상태로 만들어 복구 불가능하게 만들 수 있습니다. 그러나 PlayFab에는 이러한 경우를 안전하게 감지하고 경고할 수 있는 옵션이 있습니다.
• 이 시나리오의 모든 활동은 Device2에서 이루어집니다. 시작하려면 두 번째 기기의 사용자 로그인 흐름을 반대로 해야 합니다. 사용자에게 복구 가능한 메커니즘을 통해 로그인할 수 있는 옵션을 제공해야 하며, 기기 ID로 자동 로그인해서는 안 됩니다.

이 단계를 수행하지 않으면 플레이어가 만들 의도가 없었던 계정을 잃을 것이라는 경고를 받는 어색한 플레이어 경험이 발생합니다. 따라서 다양한 조건에 대한 흐름은 다음과 같으며, 모든 경우에 하나의 플레이어 계정만 있고 여기에 복구 가능 계정이 연결되어 있다는 점에 유의하세요. Device1 상태: Device ID가 플레이어 계정에 바인딩되어 있습니다. Device2 상태: Device ID가 플레이어 계정에 바인딩되어 있지 않습니다.

• Device2에서 (복구 가능 계정 자격 증명을 사용하여) 플레이어 계정에 로그인한 후 GetPlayerCombinedInfo를 호출합니다.
  • 해당 정보에서 반환된 각 기기 유형에 대해 result.InfoResultPayload.AccountInfo에 가장 최근에 로그인한 기기 ID가 반환됩니다.

Device2가 아직 이 플레이어 계정에 연결되지 않았기 때문에 관련 기기 ID(AccountInfo.IosDeviceInfo, AccountInfo.AndroidDeviceInfo 등)는 Device2 ID와 일치하지 않습니다. Device1 상태: Device ID가 플레이어 계정에 바인딩되어 있습니다. Device2 상태: 복구 가능 자격 증명으로 로그인되어 있지만 Device ID가 플레이어 계정에 바인딩되어 있지 않습니다. 이제 Device2가 이 계정에 바인딩되지 않았음을 확인했으므로 바인딩을 시도할 수 있습니다.

• 적절한 LinkAndroidDeviceID, LinkIOSDeviceID 또는 기타 기기별 API 호출을 실행합니다.
• 성공하면 완료된 것이며, 정상 게임 플레이를 재개합니다.
• 하지만 모든 API 호출과 마찬가지로 오류 캡처를 준비하세요. 특히 기기가 이미 계정에 연결되어 있다는 오류 반환을 찾아보세요.
• 이 조건에서는 플레이어에게 이 기기를 이 계정에 바인딩하시겠습니까 메시지를 표시하세요.
• 계속 진행하면 다른 계정을 잃을 수 있다는 정보를 반드시 제공하세요.
• 플레이어가 이 경고를 수락하면 ForceLink 속성을 True로 설정하여 연결 요청을 다시 보냅니다.
• 이렇게 하면 Device2 ID가 이전 계정에서 연결 해제되고(다른 로그인 메커니즘이 연결되어 있지 않다면 해당 계정이 고아 상태가 될 수 있음), 새 계정에 바인딩됩니다.

​

모범 사례

CloudScript 또는 PlayStream 이벤트를 사용하여 플레이어가 실수한 경우 고객 서비스 담당자가 복구할 수 있는 곳에 버려진 계정에 대한 정보를 기록하세요. Device1 상태: Device ID가 플레이어 계정에 바인딩되어 있습니다. Device2 상태: Device ID가 플레이어 계정에 바인딩되어 있습니다. 이 시점에서 두 기기 모두 동일한 계정에서 플레이하고 있으며, 두 기기 모두 마찰 없는 로그인을 안전하게 사용할 수 있습니다.

​

기존 복구 가능 계정에 마찰 없는 기기 ID 바인딩하기

이 시나리오는 위 상황과 매우 유사하지만 복구 가능 자격 증명을 사용하여 계정이 생성되었다는 점이 다릅니다. 익명 로그인을 사후에 바인딩하여 기존 게임 로그인 화면을 마찰 없는 로그인으로 변환할 수 있습니다. 여기 단계는 위 조건과 거의 동일하지만 단일 기기(위 흐름에서 단순히 Device2에 해당)로 진행됩니다. Device 상태: Device ID가 플레이어 계정에 바인딩되어 있지 않습니다. 기기로 복구 가능 로그인을 수행한 후 GetPlayerCombinedInfo를 호출합니다. 다시 result.InfoResultPayload.AccountInfo에서 반환된 정보를 통해 기기 ID가 바인딩된 기기 ID와 일치하는지 확인합니다. 기기가 계정에 로그인한 적이 없기 때문에 관련 기기 ID(AccountInfo.IosDeviceInfo, AccountInfo.AndroidDeviceInfo 등)는 기기 ID와 일치하지 않습니다. Device 상태: 복구 가능 자격 증명으로 로그인되어 있지만 기기 ID가 플레이어 계정에 바인딩되어 있지 않습니다. 기기가 이 계정에 바인딩되지 않았으므로 바인딩을 시도할 수 있습니다. 적절한 LinkAndroidDeviceID, LinkIOSDeviceID 또는 기타 기기별 API 호출을 실행하세요. 성공하면 완료된 것이며, 정상 게임 플레이를 재개합니다. 그러나 다시 말하지만 오류 캡처를 준비하세요. 특히 기기가 이미 계정에 연결되어 있다는 오류 반환을 찾아보세요. 이 조건에서는 플레이어에게 이 기기를 이 계정에 바인딩하시겠습니까 메시지를 표시하세요. 계속 진행하면 다른 계정을 잃을 수 있다는 정보를 반드시 제공하세요. 플레이어가 이 경고를 수락하면 ForceLink 속성을 True로 설정하여 연결 요청을 다시 보냅니다. 이렇게 하면 기기 ID가 이전 계정에서 연결 해제되고(다른 로그인 메커니즘이 연결되어 있지 않다면 해당 계정이 고아 상태가 될 수 있음), 새 계정에 바인딩됩니다. 모범 사례: CloudScript 또는 PlayStream 이벤트를 사용하여 플레이어가 실수한 경우 고객 서비스 담당자가 복구할 수 있는 곳에 버려진 계정에 대한 정보를 기록하세요. PlayFabId를 클라우드 기반 로그 파일에 기록하는 것과 같은 간단한 작업만으로도 열성적인 플레이어의 계정을 저장할 수 있습니다. Device 상태: 기기 ID가 플레이어 계정에 바인딩되어 있습니다. 이 시점에서 복구 가능 자격 증명 대신 기기로 마찰 없는 로그인을 사용할 수 있습니다.

​

기타 모범 사례

위 단계는 로그인 전에 사용자에게 안내하는 것을 포함합니다. 마찰 없는 로그인은 플레이어에게 먼저 묻지 않고 로그인하는 것을 포함합니다. 다음 제안 사항으로 이상적인 중간 지점을 찾을 수 있습니다. 마찰 없는 로그인 API: 모든 마찰 없는 로그인에는 CreateAccount라는 요청 매개변수가 있습니다. 예시:

• AndroidRequest.CreateAccount
• IosRequest.CreateAccount. 다음 지침에 따라 이 속성에 대해 true 또는 false를 선택하세요.

시작 시:

• 로그인 화면에서 게임은 즉시 CreateAccount=false로 마찰 없는 로그인을 시도할 수 있습니다. 성공하면 이 플레이어는 이 기기로 이미 게임에 로그인한 적이 있으며, 게임 화면으로 안전하게 바로 건너뛸 수 있습니다. 이 호출의 오류 콜백을 캡처하여 최초 로그인 옵션을 표시하도록 하세요.
• 최초 로그인 화면: 마찰 없는 로그인 기능이 있는 기기의 경우 이 화면에는 Play Now 버튼과 함께 플레이어가 Facebook, Twitch, Google 또는 기타 복구 가능 로그인 옵션을 통해 기존 계정에 로그인할 수 있는 버튼이 포함되어야 합니다. Play Now 버튼은 CreateAccount=true로 마찰 없는 로그인을 활성화해야 합니다.
• 로그아웃: 최초 로그인 화면으로 돌아가지만 마찰 없는 로그인을 자동으로 활성화하지 않는 Log Out 버튼을 제공하세요. 이를 통해 사용자는 복구 가능 옵션으로 로그인하고 그 계정에 기기를 바인딩함으로써 기기에 바인딩된 계정을 포기할 수 있는 옵션을 가지게 됩니다.

이러한 제안을 통해 사용자에게 동일한 계정에 여러 기기를 바인딩할 때 계정을 포기하도록 요청하는 대부분의 어색한 시나리오를 피할 수 있습니다.