สร้างขั้นตอนเข้าสู่ระบบด้วยตัวเอง

ในการเข้าสู่ระบบผ่านเบราว์เซอร์สำหรับเว็บหรือแอพบนเดสก์ท็อปโดยไม่ใช้ SDK ของเรา เช่นในตัวแสดงหน้าเว็บสำหรับแอพบนเดสก์ท็อปแบบเนทีฟ (ตัวอย่างเช่น Windows 8) หรือขั้นตอนการเข้าสู่ระบบที่ใช้โค้ดฝั่งเซิร์ฟเวอร์เพียงอย่างเดียว คุณสามารถสร้างขั้นตอนการเข้าสู่ระบบสำหรับตัวคุณเองได้โดยใช้การเปลี่ยนเส้นทางเบราว์เซอร์ คู่มือนี้จะช่วยแนะนำขั้นตอนการเข้าสู่ระบบแต่ละขั้นตอนและแสดงวิธีใช้ขั้นตอนเหล่านั้นโดยไม่ต้องพึ่งพา SDK ของเราให้คุณได้ทราบ ดังนี้

• การตรวจสอบสถานะการเข้าสู่ระบบ
• การนำผู้ใช้เข้าสู่ระบบ
• การยืนยันตัวตน
• การจัดเก็บโทเค็นการเข้าถึงและสถานะการเข้าสู่ระบบ
• การนำผู้ใช้ออกจากระบบ
• การตรวจจับเมื่อผู้ใช้ถอนการติดตั้งแอพ
• การตอบกลับคำขอให้ลบข้อมูลผู้ใช้

การตรวจสอบสถานะการเข้าสู่ระบบ

แอพที่ใช้ SDK ของเราสามารถตรวจสอบว่าผู้ใช้เข้าสู่ระบบแล้วหรือไม่โดยใช้ฟังก์ชั่นในตัว แอพอื่นๆ ทั้งหมดต้องสร้างวิธีของตนเองในการจัดเก็บเมื่อมีผู้ใช้เข้าสู่ระบบ และเมื่อไม่มีตัวบ่งชี้ดังกล่าว ให้ดำเนินการต่อโดยสันนิษฐานว่าผู้ใช้ได้ออกจากระบบไปแล้ว หากมีผู้ใช้ออกจากระบบ แอพของคุณควรเปลี่ยนเส้นทางผู้ใช้ไปยังกล่องการเข้าสู่ระบบในเวลาที่เหมาะสม ตัวอย่างเช่น หากผู้ใช้คลิกปุ่มเข้าสู่ระบบ

การนำผู้ใช้เข้าสู่ระบบ

ไม่ว่าผู้ใช้จะไม่ได้เข้าสู่ระบบแอพของคุณหรือไม่ได้เข้าสู่ระบบ Facebook คุณก็สามารถใช้กล่องการเข้าสู่ระบบเพื่อแจ้งให้ผู้ใช้เข้าสู่ทั้ง 2 ระบบได้ หากผู้ใช้ยังไม่ได้เข้าสู่ระบบ Facebook พวกเขาจะได้รับแจ้งให้เข้าสู่ระบบ จากนั้นจึงเข้าสู่ระบบแอพของคุณ การตรวจจับนี้เป็นกระบวนการอัตโนมัติ คุณจึงไม่จำเป็นต้องทำอะไรเพิ่มเติมเพื่อเปิดใช้งานกระบวนการนี้

การเรียกใช้กล่องการเข้าสู่ระบบและการตั้งค่า URL การเปลี่ยนเส้นทาง

แอพของคุณต้องเริ่มเปลี่ยนเส้นทางไปยังตำแหน่งข้อมูลที่จะแสดงกล่องการเข้าสู่ระบบ:

https://www.facebook.com/v19.0/dialog/oauth?
  client_id={app-id}
  &redirect_uri={redirect-uri}
  &state={state-param}

ตำแหน่งข้อมูลนี้มีพารามิเตอร์ที่จำเป็นดังต่อไปนี้:

• client_id ID ของแอพที่พบในแดชบอร์ดของแอพของคุณ
• redirect_uri URL ที่คุณต้องการเปลี่ยนเส้นทางผู้ใช้ที่กำลังเข้าสู่ระบบให้กลับไป URL นี้จะจับการตอบกลับจากกล่องการเข้าสู่ระบบ หากคุณใช้ URL นี้ในตัวแสดงหน้าเว็บภายในแอพบนเดสก์ท็อป URL นี้จะต้องตั้งค่าเป็น https://www.facebook.com/connect/login_success.html คุณสามารถยืนยันได้ว่า URL นี้ได้ตั้งค่าสำหรับแอพของคุณแล้วในแดชบอร์ดของแอพ ในส่วนสินค้าในเมนูการนำทางด้านซ้ายของแดชบอร์ดของแอพ ให้คลิกการเข้าสู่ระบบด้วย Facebook จากนั้นคลิกการตั้งค่า ตรวจสอบยืนยัน URI การเปลี่ยนเส้นทาง OAuth ที่ถูกต้องในส่วนการตั้งค่า OAuth ไคลเอ็นต์
• state ค่าสตริงที่แอพของคุณสร้างขึ้นเพื่อรักษาสถานะระหว่างการส่งคำขอและการเรียกกลับ พารามิเตอร์นี้ควรนำมาใช้เพื่อป้องกันการปลอมแปลงคำขอข้ามเว็บไซต์และจะเป็นพารามิเตอร์ที่ระบบส่งกลับให้คุณใน URI การเปลี่ยนเส้นทางของคุณโดยไม่มีการเปลี่ยนแปลง

ตัวอย่างเช่น หากคำขอเข้าสู่ระบบของคุณมีลักษณะดังนี้

https://www.facebook.com/v19.0/dialog/oauth?
  client_id={app-id}
  &redirect_uri={"https://www.domain.com/login"}
  &state={"{st=state123abc,ds=123456789}"}

URI การเปลี่ยนเส้นทางของคุณก็จะถูกเรียกใช้ด้วย:

https://www.domain.com/login?state="{st=state123abc,ds=123456789}"
    

และจะมีพารามิเตอร์ที่ไม่บังคับดังต่อไปนี้:

• response_type พิจารณาว่าเมื่อมีการเปลี่ยนเส้นทางกลับไปยังแอพ ข้อมูลการตอบกลับที่ส่งมานั้นอยู่ในพารามิเตอร์หรือองค์ประกอบย่อยของ URL หรือไม่ ดูส่วนการยืนยันตัวตนเพื่อเลือกประเภทที่แอพของคุณควรใช้ ซึ่งอาจเป็นหนึ่งในรายการต่อไปนี้:

  • code ข้อมูลการตอบกลับจะรวมอยู่เป็นพารามิเตอร์ URL และมีพารามิเตอร์ code (สตริงที่มีการเข้ารหัสซึ่งไม่ซ้ำกันสำหรับคำขอเข้าสู่ระบบแต่ละรายการ) กระบวนการนี้จะเป็นค่าเริ่มต้นหากไม่มีการระบุพารามิเตอร์นี้ โดยจะมีประโยชน์ที่สุดเมื่อเซิร์ฟเวอร์ของคุณจะดำเนินการกับโทเค็น
  • token ข้อมูลการตอบกลับจะรวมอยู่เป็นองค์ประกอบย่อยของ URL และมีโทเค็นการเข้าถึง แอพบนเดสก์ท็อปต้องใช้การตั้งค่านี้สำหรับ response_type โดยจะมีประโยชน์ที่สุดเมื่อไคลเอ็นต์จะดำเนินการกับโทเค็น
  • code%20token. ข้อมูลการตอบกลับจะรวมอยู่เป็นองค์ประกอบย่อยของ URL และมีทั้งโทเค็นการเข้าถึงและพารามิเตอร์ code
  • granted_scopes ส่งคืนรายการสิทธิ์การอนุญาตทั้งหมดที่ผู้ใช้ให้กับแอพในเวลาที่เข้าสู่ระบบ โดยคั่นด้วยเครื่องหมายจุลภาค สามารถรวมกับค่า response_type อื่นๆ ได้ เมื่อรวมกับ token ข้อมูลการตอบกลับจะรวมอยู่เป็นองค์ประกอบย่อยของ URL ไม่เช่นนั้นจะรวมอยู่เป็นพารามิเตอร์ URL
• scope รายการสิทธิ์การอนุญาตที่คั่นด้วยเครื่องหมายจุลภาคหรือการเว้นวรรคในการส่งคำขอจากผู้ใช้แอพของคุณ

สำหรับแอพบน Windows 8

หากคุณกำลังสร้างการเข้าสู่ระบบสำหรับแอพบน Windows คุณสามารถใช้ตัวระบุเพื่อความปลอดภัยของแพ็คเกจเป็น redirect_uri ของคุณเองได้ แล้วกระตุ้นการทำงานของกล่องการเข้าสู่ระบบด้วยการเรียกใช้ WebAuthenticationBroker.AuthenticateAsync และใช้ตำแหน่งข้อมูลของกล่องการเข้าสู่ระบบเป็น URI คำขอ โดยตัวอย่างในรูปแบบ JavaScript มีดังนี้

var requestUri = new Windows.Foundation.Uri(
  "https://www.facebook.com/v19.0/dialog/oauth?
    client_id={app-id}
    &display=popup
    &response_type=token
    &redirect_uri=ms-app://{package-security-identifier}");

Windows.Security.Authentication.Web.WebAuthenticationBroker.authenticateAsync(
  options,
  requestUri)
  .done(function (result) {
    // Handle the response from the Login Dialog
  }
);

การดำเนินการนี้จะส่งคืนขั้นตอนการควบคุมกลับไปยังแอพของคุณด้วยโทเค็นการเข้าถึงเมื่อสำเร็จ หรือส่งคืนข้อผิดพลาดเมื่อล้มเหลว

การจัดการการตอบกลับกล่องการเข้าสู่ระบบ

เมื่อถึงจุดนี้ในขั้นตอนเข้าสู่ระบบ ผู้ใช้จะเห็นกล่องการเข้าสู่ระบบและจะมีตัวเลือกว่าจะยกเลิกหรือปล่อยให้แอพเข้าถึงข้อมูลของตนเองได้

หากผู้ใช้แอพเลือก "ตกลง" บนกล่องการเข้าสู่ระบบ จะเป็นการอนุญาตให้แอพเข้าถึงโปรไฟล์สาธารณะ รายชื่อเพื่อน และสิทธิ์การอนุญาตเพิ่มเติมใดๆ ที่แอพของคุณร้องขอ

ในทุกกรณี เบราว์เซอร์จะย้อนกลับไปยังแอพ และจะมีข้อมูลการตอบกลับที่ระบุว่าผู้ใช้ได้เชื่อมต่อหรือยกเลิกด้วย เมื่อแอพของคุณใช้วิธีการเปลี่ยนเส้นทางข้างต้น redirect_uri ที่แอพของคุณย้อนกลับไปยังจะถูกต่อท้ายด้วยพารามิเตอร์หรือองค์ประกอบย่อยของ URL (ตาม response_type ที่เลือก) ซึ่งจะต้องบันทึกไว้

คู่มือของเราไม่แสดงตัวอย่างที่เฉพาะเจาะจงเนื่องจากมีชุดภาษาโค้ดที่หลากหลายที่สามารถใช้ได้ในแอพบนเว็บ อย่างไรก็ตาม ภาษาร่วมสมัยส่วนใหญ่จะสามารถแยกวิเคราะห์ URL ได้ ดังนี้

JavaScript ฝั่งไคลเอ็นต์จะสามารถบันทึกองค์ประกอบย่อยของ URL ได้ (ตัวอย่างเช่น jQuery BBQ) ขณะที่พารามิเตอร์ URL สามารถบันทึกได้โดยทั้งโค้ดฝั่งไคลเอ็นต์และฝั่งเซิร์ฟเวอร์ (ตัวอย่างเช่น $_GET เป็นภาษา PHP, jQuery.deparam เป็นภาษา jQuery BBQ, querystring.parse เป็นภาษา Node.js หรือ urlparse เป็นภาษา Python) โดย Microsoft มีคู่มือและโค้ดตัวอย่างสำหรับแอพบน Windows 8 ที่เชื่อมต่อกับ "ผู้ให้บริการออนไลน์" ซึ่งในกรณีนี้คือ Facebook ไว้ให้

https://www.facebook.com/connect/login_success.html#
    access_token=ACCESS_TOKEN...

การเข้าสู่ระบบที่ถูกยกเลิก

หากผู้ใช้แอพของคุณไม่ยอมรับกล่องการเข้าสู่ระบบและคลิกยกเลิก ผู้ใช้จะถูกเปลี่ยนเส้นทางไปยังปลายทางต่อไปนี้:

YOUR_REDIRECT_URI?
 error_reason=user_denied
 &error=access_denied
 &error_description=Permissions+error.

ดูข้อมูลเพิ่มเติมเกี่ยวกับสิ่งที่แอพควรทำเมื่อผู้ใช้ปฏิเสธที่จะเข้าสู่ระบบได้ในการดำเนินการเมื่อไม่ได้รับสิทธิ์การอนุญาต

การยืนยันตัวตน

เนื่องจากขั้นตอนเปลี่ยนเส้นทางนี้จะเปลี่ยนเส้นทางเบราว์เซอร์ไปยัง URL ในแอพของคุณจากกล่องการเข้าสู่ระบบ ดังนั้น ผู้เข้าชมจึงสามารถเข้าถึง URL นี้ได้โดยตรงด้วยองค์ประกอบย่อยหรือพารามิเตอร์ที่สร้างขึ้น หากแอพของคุณสันนิษฐานว่าพารามิเตอร์เหล่านี้ถูกต้อง แอพของคุณจะใช้ข้อมูลที่สร้างขึ้นเพื่อวัตถุประสงค์ที่อาจเป็นอันตราย ด้วยเหตุนี้ แอพของคุณจึงควรยืนยันว่าผู้ใช้แอพเป็นบุคคลเดียวกับที่คุณมีข้อมูลการตอบกลับก่อนสร้างโทเค็นการเข้าถึงสำหรับผู้ใช้ดังกล่าว การยืนยันตัวตนสามารถทำได้หลายวิธีโดยขึ้นอยู่กับ response_type ที่ได้รับข้างต้น:

• เมื่อได้รับ code จะต้องแลกเปลี่ยนเป็นโทเค็นการเข้าถึงโดยใช้ตำแหน่งข้อมูล การเรียกใช้จะต้องเป็นแบบเซิร์ฟเวอร์ถึงเซิร์ฟเวอร์ เนื่องจากมีข้อมูลลับของแอพคุณอยู่ (ข้อมูลลับของแอพไม่ควรไปอยู่ในโค้ดของไคลเอ็นต์)
• เมื่อได้รับ token จะต้องได้รับการตรวจสอบยืนยัน คุณควรทำการเรียกใช้ API ไปยังตำแหน่งข้อมูลการตรวจสอบซึ่งจะระบุว่าโทเค็นนั้นถูกสร้างขึ้นมาเพื่อใครและสร้างโดยแอพใด เนื่องจากการเรียกใช้ API นี้ต้องใช้โทเค็นการเข้าถึงแอพ จึงห้ามทำการเรียกใช้นี้จากไคลเอ็นต์ แต่ให้ทำการเรียกใช้จากเซิร์ฟเวอร์ที่คุณสามารถจัดเก็บข้อมูลลับของแอพได้อย่างปลอดภัย
• เมื่อได้รับทั้ง code และ token ควรดำเนินการทั้ง 2 ขั้นตอน

โปรดทราบว่าคุณยังสามารถสร้างstateพารามิเตอร์ของคุณเองและใช้กับคำขอเข้าสู่ระบบของคุณเพื่อให้การป้องกัน CSRF ได้เช่นกัน

การแลกเปลี่ยนโค้ดเป็นโทเค็นการเข้าถึง

ในการรับโทเค็นการเข้าถึง ให้ส่งคำขอ HTTP GET ไปยังตำแหน่งข้อมูล OAuth ต่อไปนี้:

GET https://graph.facebook.com/v19.0/oauth/access_token?
   client_id={app-id}
   &redirect_uri={redirect-uri}
   &client_secret={app-secret}
   &code={code-parameter}

ตำแหน่งข้อมูลนี้มีพารามิเตอร์ที่จำเป็นดังต่อไปนี้:

• client_id ID ของแอพของคุณ
• redirect_uri จำเป็นต้องมีอาร์กิวเมนต์นี้ และจะต้องเป็นอาร์กิวเมนต์เดียวกับ request_uri ดั้งเดิมที่คุณใช้เมื่อเริ่มกระบวนการเข้าสู่ระบบ OAuth
• client_secret ข้อมูลลับของแอพที่ไม่ซ้ำกันของคุณดังที่แสดงในแดชบอร์ดของแอพ ห้ามใส่ข้อมูลลับของแอพนี้ในโค้ดของฝั่งไคลเอ็นต์หรือในไบนารีที่สามารถทำการแยกส่วนได้ สิ่งสำคัญอย่างยิ่งคือข้อมูลลับจะต้องเป็นความลับอย่างที่สุดเนื่องจากเป็นหัวใจสำคัญของความปลอดภัยของแอพและผู้ใช้แอพทุกคน
• code พารามิเตอร์ที่ได้รับจากการเปลี่ยนเส้นทางของกล่องการเข้าสู่ระบบข้างต้น

หมายเหตุ: ตั้งแต่เวอร์ชั่น 2.3 เป็นต้นไป ตำแหน่งข้อมูลนี้จะส่งคืนการตอบกลับ JSON ที่เหมาะสม หากการเรียกใช้ของคุณไม่ระบุเวอร์ชั่น ระบบจะใช้ค่าเริ่มต้นเป็นเวอร์ชั่นเก่าที่สุดที่พร้อมใช้งาน

การตอบกลับ

การตอบกลับที่คุณจะได้รับจากตำแหน่งข้อมูลนี้จะถูกส่งคืนในรูปแบบ JSON และหากสำเร็จ ก็จะเป็น:

{
  "access_token": {access-token}, 
  "token_type": {type},
  "expires_in":  {seconds-til-expiration}
}

หากไม่สำเร็จ คุณจะได้รับข้อความอธิบายข้อผิดพลาด

การตรวจสอบโทเค็นการเข้าถึง

ไม่ว่าแอพของคุณจะใช้ code หรือ token เป็น response_type จากกล่องการเข้าสู่ระบบหรือไม่ แอพก็จะได้รับโทเค็นการเข้าถึง คุณสามารถดำเนินการตรวจสอบโทเค็นเหล่านี้โดยอัตโนมัติโดยใช้ตำแหน่งข้อมูล API กราฟ:

GET graph.facebook.com/debug_token?
     input_token={token-to-inspect}
     &access_token={app-token-or-admin-token}

ตำแหน่งข้อมูลนี้ใช้พารามิเตอร์ต่อไปนี้:

• input_token โทเค็นที่ต้องตรวจสอบ
• access_tokenโทเค็นการเข้าถึงแอพหรือโทเค็นการเข้าถึงสำหรับผู้พัฒนาแอพนี้

การตอบกลับการเรียกใช้ API จะเป็นอาร์เรย์ JSON ที่มีข้อมูลเกี่ยวกับโทเค็นที่ตรวจสอบ ตัวอย่างเช่น:

{
    "data": {
        "app_id": 138483919580948, 
        "type": "USER",
        "application": "Social Cafe", 
        "expires_at": 1352419328, 
        "is_valid": true, 
        "issued_at": 1347235328, 
        "metadata": {
            "sso": "iphone-safari"
        }, 
        "scopes": [
            "email", 
            "publish_actions"
        ], 
        "user_id": "1207059"
    }
}

ช่อง app_id และ user_id ช่วยให้แอพตรวจสอบยืนยันว่าโทเค็นการเข้าถึงนั้นใช้งานได้สำหรับผู้ใช้และแอพของคุณ โปรดดูคำอธิบายสำหรับช่องอื่นๆ แบบละเอียดได้ในคู่มือการรับข้อมูลเกี่ยวกับโทเค็นการเข้าถึง

การตรวจสอบสิทธิ์การอนุญาต

คุณสามารถเรียกใช้จุดเชื่อมโยง /me/permissions ได้เพื่อกู้คืนรายการสิทธิ์การอนุญาตที่ผู้ใช้รายใดรายหนึ่งได้ให้หรือปฏิเสธ แอพของคุณสามารถใช้จุดเชื่อมโยงนี้เพื่อตรวจสอบว่ามีสิทธิ์การอนุญาตที่ร้องขอใดบ้างที่แอพไม่สามารถใช้ได้สำหรับผู้ใช้รายใดรายหนึ่ง

การขอสิทธิ์การอนุญาตที่ถูกปฏิเสธอีกครั้ง

การเข้าสู่ระบบด้วย Facebook ช่วยให้ผู้ใช้สามารถปฏิเสธการแชร์สิทธิ์การอนุญาตบางอย่างกับแอพของคุณได้ กล่องการเข้าสู่ระบบจะมีหน้าจอลักษณะดังนี้:

ต้องมีสิทธิ์การอนุญาต public_profile และจะต้องแสดงเป็นสีเทาเสมอเนื่องจากไม่สามารถปิดใช้งานได้

อย่างไรก็ตาม หากมีผู้ใช้เลิกทำเครื่องหมาย user_likes (ถูกใจ) ในตัวอย่างนี้ การทำเครื่องหมาย /me/permissions สำหรับสิทธิ์ที่ได้รับอนุญาตจะส่งผลดังนี้:

{
  "data":
    [
      {
        "permission":"public_profile",
        "status":"granted"
      },
      {
        "permission":"user_likes",
        "status":"declined"
      }
    ]
}

โปรดทราบว่า user_likes ถูกปฏิเสธแทนที่จะได้รับอนุญาต

สำหรับสิทธิ์การอนุญาตที่ผู้ใช้ปฏิเสธ คุณสามารถขอให้ผู้ใช้ให้สิทธิ์ดังกล่าวแก่แอพของคุณอีกครั้งได้ คุณควรมีหน้าจอสำหรับให้ความรู้แก่ผู้ใช้เกี่ยวกับเหตุผลที่คุณคิดว่าผู้ใช้ควรให้สิทธิ์การอนุญาตแก่คุณ จากนั้นจึงขออีกครั้ง แต่ถ้าคุณเรียกใช้กล่องการเข้าสู่ระบบเหมือนก่อนหน้านี้ ระบบจะไม่ขอสิทธิ์การอนุญาตดังกล่าว

เนื่องจากเมื่อผู้ใช้ปฏิเสธที่จะให้สิทธิ์การอนุญาต กล่องการเข้าสู่ระบบจะไม่ขอสิทธิ์การอนุญาตจากผู้ใช้อีกครั้ง ยกเว้นในกรณีที่คุณระบุในกล่องโต้ตอบอย่างชัดเจนว่าคุณต้องการขอสิทธิ์การอนุญาตที่ถูกปฏิเสธอีกครั้ง

คุณสามารถทำได้ด้วยการเพิ่มพารามิเตอร์ auth_type=rerequest ไปยัง URL ของกล่องการเข้าสู่ระบบของคุณ:

https://www.facebook.com/v19.0/dialog/oauth?
    client_id={app-id}
    &redirect_uri={redirect-uri}
    &auth_type=rerequest
    scope=email
   

การใช้พารามิเตอร์นี้จะทำให้กล่องการเข้าสู่ระบบขอสิทธิ์การอนุญาตที่ถูกปฏิเสธอีกครั้ง

การจัดเก็บโทเค็นการเข้าถึงและสถานะการเข้าสู่ระบบ

เมื่อถึงจุดนี้ คุณจะมีผู้ใช้ที่ผ่านการยืนยันตัวตนและเข้าสู่ระบบแล้ว แอพของคุณพร้อมทำการเรียกใช้ API ในนามของผู้ใช้แล้ว ก่อนที่จะดำเนินการดังกล่าว แอพควรจัดเก็บโทเค็นการเข้าถึงและสถานะการเข้าสู่ระบบของผู้ใช้แอพด้วย

การจัดเก็บโทเค็นการเข้าถึง

หลังจากที่แอพได้รับโทเค็นการเข้าถึงจากขั้นตอนที่แล้ว โทเค็นนั้นควรจัดเก็บไว้เพื่อให้ใช้งานได้ในทุกส่วนของแอพเมื่อทำการเรียกใช้ API ขั้นตอนนี้ไม่มีกระบวนการที่เฉพาะเจาะจง อย่างไรก็ตามโดยทั่วไปแล้ว หากคุณกำลังสร้างแอพบนเว็บ วิธีที่ดีที่สุดคือการเพิ่มโทเค็นเป็นตัวแปรของเซสชั่นเพื่อระบุเซสชั่นเบราว์เซอร์ดังกล่าวที่มีผู้ใช้คนนั้นอยู่ หากคุณกำลังสร้างแอพบนเดสก์ท็อปหรือแอพบนมือถือแบบเนทีฟ คุณควรใช้พื้นที่จัดเก็บข้อมูลที่มีให้สำหรับแอพของคุณ นอกจากนี้ แอพควรจัดเก็บโทเค็นไว้ในฐานข้อมูลร่วมกับ user_id เพื่อระบุตัวตน

โปรดดูหมายเหตุเรื่องขนาดของโทเค็นการเข้าถึงในเอกสารเกี่ยวกับโทเค็นการเข้าถึง

การติดตามสถานะการเข้าสู่ระบบ

เช่นเดียวกัน แอพของคุณควรจัดเก็บสถานะการเข้าสู่ระบบของผู้ใช้ ซึ่งช่วยเลี่ยงการเรียกไปยังกล่องการเข้าสู่ระบบเพิ่มเติมอีก ไม่ว่าคุณจะเลือกใช้กระบวนการใด ให้ปรับแต่งการตรวจสอบสถานะการเข้าสู่ระบบให้เหมาะสมกับกระบวนการ

การนำผู้ใช้ออกจากระบบ

คุณสามารถนำผู้ใช้ออกจากระบบแอพของคุณได้ด้วยการยกเลิกตัวบ่งชี้สถานะการเข้าสู่ระบบใดๆ ที่คุณได้เพิ่มไว้ ตัวอย่างเช่นการลบเซสชั่นที่บ่งชี้ว่ามีผู้ใช้เข้าสู่ระบบ นอกจากนี้ คุณควรลบโทเค็นการเข้าถึงที่จัดเก็บไว้ด้วย

การนำผู้ใช้ออกจากระบบไม่เหมือนกับการเพิกถอนสิทธิ์การอนุญาตในการเข้าสู่ระบบ (การลบการยืนยันตัวตนที่อนุมัติก่อนหน้านี้) ซึ่งสามารถดำเนินการแยกต่างหากได้ ด้วยเหตุนี้ ขอแนะนำให้สร้างแอพของคุณในลักษณะที่ไม่บังคับให้ผู้ใช้ที่ออกจากระบบย้อนกลับไปยังกล่องการเข้าสู่ระบบโดยอัตโนมัติ

การตรวจจับเมื่อผู้ใช้ถอนการติดตั้งแอพ

ผู้ใช้สามารถถอนการติดตั้งแอพผ่าน Facebook.com ได้โดยไม่ต้องโต้ตอบกับแอพนั้นๆ เราจึงช่วยให้แอพได้ตรวจจับการถอนการติดตั้ง โดยอนุญาตให้แอพระบุ URL การเรียกกลับเพื่อเลิกให้อนุญาตซึ่งจะได้รับข้อมูลทุกครั้งที่มีการถอนการติดตั้ง

คุณสามารถเปิดใช้งานการเรียกกลับเพื่อเลิกให้อนุญาตได้ผ่านทางแดชบอร์ดของแอพ

การตอบกลับคำขอให้ลบข้อมูลผู้ใช้

ผู้ใช้สามารถขอให้แอพลบข้อมูลที่เกี่ยวกับตนเองทั้งหมดที่ได้รับจาก Facebook ได้ ในการตอบกลับคำขอเหล่านี้ โปรดดูการเรียกกลับคำขอการลบข้อมูล