ประเภทการลิงก์ OAuth รองรับขั้นตอน OAuth 2.0 มาตรฐานอุตสาหกรรม 2 ขั้นตอน ได้แก่ ขั้นตอนของรหัสโดยนัยและการให้สิทธิ์
ในขั้นตอนการเขียนโค้ดแบบโดยนัย Google จะเปิดปลายทางการให้สิทธิ์ในเบราว์เซอร์ของผู้ใช้ เมื่อลงชื่อเข้าใช้สําเร็จ คุณจะส่งคืนโทเค็นเพื่อการเข้าถึงที่ใช้ได้นานแก่ Google ตอนนี้โทเค็นเพื่อการเข้าถึงนี้รวมอยู่ในคําขอทุกรายการที่ส่งจาก Assistant ไปยังการดําเนินการของคุณแล้ว
ในกระบวนการรหัสการให้สิทธิ์ คุณต้องมีปลายทาง 2 จุด ได้แก่
- ปลายทางการให้สิทธิ์ ซึ่งมีหน้าที่นําเสนอ UI การลงชื่อเข้าใช้แก่ผู้ใช้ที่ไม่ได้ลงชื่อเข้าใช้ และยินยอมให้มีการเข้าถึงการเข้าถึงที่ขอในรูปของรหัสการให้สิทธิ์ระยะสั้น
- ปลายทางของการแลกเปลี่ยนโทเค็นที่มีหน้าที่รับผิดชอบการแลกเปลี่ยน 2 ประเภท ได้แก่
- แลกเปลี่ยนรหัสการให้สิทธิ์สําหรับโทเค็นการรีเฟรชที่ใช้ได้นานและโทเค็นเพื่อการเข้าถึงที่ใช้ได้นาน การแลกเปลี่ยนนี้จะเกิดขึ้นเมื่อผู้ใช้เข้าสู่ กระบวนการเชื่อมโยงบัญชี
- แลกเปลี่ยนโทเค็นการรีเฟรชที่ใช้ได้นานกับโทเค็นเพื่อการเข้าถึงที่ใช้ได้ในระยะสั้น Exchange นี้จะเกิดขึ้นเมื่อ Google ต้องการโทเค็นเพื่อการเข้าถึงใหม่เนื่องจากโทเค็นหมดอายุ
แม้ว่าขั้นตอนการใช้รหัสโดยนัยจะง่ายกว่า Google ขอแนะนําว่าโทเค็นเพื่อการเข้าถึงที่ออกโดยใช้โฟลว์โดยนัยไม่มีวันหมดอายุ เนื่องจากการใช้การหมดอายุของโทเค็นด้วยขั้นตอนโดยนัยบังคับให้ผู้ใช้ลิงก์บัญชีอีกครั้ง หากคุณต้องการใช้การหมดอายุของโทเค็นด้วยเหตุผลด้านความปลอดภัย คุณควรพิจารณาการใช้ขั้นตอนการตรวจสอบสิทธิ์แทน
ใช้การลิงก์บัญชี OAuth
เพื่อช่วยให้กระบวนการตรวจสอบง่ายขึ้นกำหนดค่าโปรเจ็กต์
หากต้องการกำหนดค่าโปรเจ็กต์เพื่อใช้การลิงก์ OAuth ให้ทำตามขั้นตอนต่อไปนี้
- เปิดคอนโซล Actions แล้วเลือกโปรเจ็กต์ที่ต้องการใช้
- คลิกแท็บพัฒนา และเลือกการลิงก์บัญชี
- เปิดใช้สวิตช์ข้างการลิงก์บัญชี
- ในส่วนการสร้างบัญชี ให้เลือกไม่ ฉันต้องการอนุญาตให้สร้างบัญชีบนเว็บไซต์เท่านั้น
ในประเภทการลิงก์ ให้เลือก OAuth และรหัสการให้สิทธิ์
ในส่วนข้อมูลลูกค้า:
- กำหนดค่ารหัสลูกค้าที่ออกโดย Actions to Google เพื่อระบุคำขอที่มาจาก Google
- จดบันทึกมูลค่าของรหัสลูกค้าที่ Google ออกให้กับการดำเนินการของคุณ
- ใส่ URL สำหรับปลายทางการให้สิทธิ์และการแลกเปลี่ยนโทเค็น
- คลิกบันทึก
ใช้งานเซิร์ฟเวอร์ OAuth
การใช้งานเซิร์ฟเวอร์ OAuth 2.0 สำหรับขั้นตอนของรหัสการให้สิทธิ์ประกอบด้วย 2 ปลายทางที่บริการของคุณใช้งานได้ผ่าน HTTPS ปลายทางแรก คือปลายทางการให้สิทธิ์ ซึ่งมีหน้าที่ในการค้นหาหรือรับ ความยินยอมจากผู้ใช้ในการเข้าถึงข้อมูล ปลายทางการให้สิทธิ์แสดงการลงชื่อเข้าใช้ UI ไปยังผู้ใช้ที่ยังไม่ได้ลงชื่อเข้าใช้และบันทึกความยินยอมสำหรับ ขอสิทธิ์เข้าถึง ปลายทางที่ 2 คือปลายทางการแลกเปลี่ยนโทเค็น ใช้เพื่อรับสตริงที่เข้ารหัสที่เรียกว่าโทเค็นที่ให้สิทธิ์ผู้ใช้การดำเนินการ เพื่อเข้าถึงบริการ
เมื่อการดำเนินการของคุณจำเป็นต้องเรียก API ของบริการของคุณ Google จะใช้ API เหล่านี้ อุปกรณ์ปลายทางร่วมกันเพื่อรับสิทธิ์จากผู้ใช้ในการเรียกใช้ API เหล่านี้ใน แทน
เซสชันขั้นตอนการใช้รหัสการตรวจสอบสิทธิ์ OAuth 2.0 ที่ Google เป็นผู้เริ่มจะมีขั้นตอนดังนี้
- Google จะเปิดปลายทางการให้สิทธิ์ในเบราว์เซอร์ของผู้ใช้ หากขั้นตอน เริ่มต้นในอุปกรณ์ที่มีแต่เสียงสำหรับการดำเนินการ Google จะโอน กับโทรศัพท์
ผู้ใช้ลงชื่อเข้าใช้ (หากยังไม่ได้ลงชื่อเข้าใช้) และให้สิทธิ์ Google ในการ เข้าถึงข้อมูลของตนด้วย API ของคุณหากผู้ใช้เหล่านั้นยังไม่ได้ให้สิทธิ์
บริการของคุณจะสร้างรหัสการให้สิทธิ์และส่งคืนให้ Google ภายในวันที่ เปลี่ยนเส้นทางเบราว์เซอร์ของผู้ใช้กลับไปยัง Google ด้วยรหัสการให้สิทธิ์ ที่แนบมากับคำขอ
Google จะส่งรหัสการให้สิทธิ์ไปยังปลายทางการแลกเปลี่ยนโทเค็น จะตรวจสอบความถูกต้องของโค้ดและส่งกลับโทเค็นเพื่อการเข้าถึงและ โทเค็นการรีเฟรช โทเค็นเพื่อการเข้าถึงเป็นโทเค็นที่มีอายุใช้งานสั้นที่บริการของคุณ ยอมรับเป็นข้อมูลรับรองเพื่อเข้าถึง API โทเค็นการรีเฟรชมีอายุการใช้งานที่ยาวนาน ที่ Google สามารถจัดเก็บและใช้เพื่อรับโทเค็นเพื่อการเข้าถึงใหม่ หมดอายุ
หลังจากที่ผู้ใช้ทำการลิงก์บัญชีเสร็จแล้ว ทุกครั้ง คำขอที่ส่งจาก Assistant ไปยังเว็บฮุคของการดำเนินการตามคำสั่งซื้อมี โทเค็นเพื่อการเข้าถึง
จัดการคำขอการให้สิทธิ์
เมื่อการดำเนินการของคุณต้องทำการลิงก์บัญชีผ่านรหัสการให้สิทธิ์ OAuth 2.0 Google จะส่งผู้ใช้ไปยังปลายทางการให้สิทธิ์พร้อมกับคำขอ ประกอบด้วยพารามิเตอร์ต่อไปนี้
พารามิเตอร์ปลายทางการให้สิทธิ์ | |
---|---|
client_id |
รหัสไคลเอ็นต์ของ Google ที่คุณลงทะเบียนกับ Google |
redirect_uri |
URL ที่คุณส่งการตอบกลับคำขอนี้ |
state |
มูลค่าการทำบัญชีที่ส่งกลับไปยัง Google ไม่เปลี่ยนแปลงใน URI การเปลี่ยนเส้นทาง |
scope |
ไม่บังคับ: ชุดสตริงขอบเขตที่คั่นด้วยช่องว่างซึ่งระบุฟิลด์ ข้อมูลที่ Google กำลังขออนุญาต |
response_type |
สตริง code |
ตัวอย่างเช่น หากปลายทางการให้สิทธิ์อยู่ที่ https://myservice.example.com/auth
คำขออาจมีลักษณะดังนี้
GET https://myservice.example.com/auth?client_id=GOOGLE_CLIENT_ID&redirect_uri=REDIRECT_URI&state=STATE_STRING&scope=REQUESTED_SCOPES&response_type=code
สำหรับปลายทางการให้สิทธิ์ในการจัดการคำขอลงชื่อเข้าใช้ ให้ทำตามขั้นตอนต่อไปนี้
ตรวจสอบว่า
client_id
ตรงกับรหัสไคลเอ็นต์ของ Google ที่ลงทะเบียนไว้ Google และredirect_uri
ตรงกับ URL เปลี่ยนเส้นทางที่ Google ระบุไว้ สำหรับบริการของคุณ ซึ่งการตรวจสอบเหล่านี้มีความสําคัญในการป้องกันไม่ให้ให้สิทธิ์เข้าถึง แอปไคลเอ็นต์ที่ไม่ได้ตั้งใจหรือกำหนดค่าไม่ถูกต้องหากคุณรองรับขั้นตอน OAuth 2.0 หลายขั้นตอน ให้ตรวจสอบด้วยว่า
response_type
คือcode
ตรวจสอบว่าผู้ใช้ลงชื่อเข้าใช้บริการของคุณหรือไม่ หากผู้ใช้ไม่ได้ลงชื่อเข้าใช้ ดำเนินการตามขั้นตอนการลงชื่อเข้าใช้หรือลงชื่อสมัครใช้บริการให้เสร็จสิ้น
สร้างรหัสการให้สิทธิ์ที่ Google จะใช้เพื่อเข้าถึง API ของคุณ รหัสการให้สิทธิ์จะเป็นค่าสตริงใดก็ได้ แต่ต้องไม่ซ้ำกัน แสดงผู้ใช้ ไคลเอ็นต์ที่ใช้โทเค็น และวันหมดอายุของรหัส และไม่ควรคาดเดาได้ โดยปกติแล้วคุณจะออกการให้สิทธิ์ ซึ่งจะหมดอายุหลังจากผ่านไปประมาณ 10 นาที
ยืนยันว่า URL ที่ระบุโดยพารามิเตอร์
redirect_uri
มีรูปแบบต่อไปนี้ วันที่https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID
YOUR_PROJECT_ID คือรหัสในหน้าการตั้งค่าโปรเจ็กต์ ของคอนโซลการดำเนินการเปลี่ยนเส้นทางเบราว์เซอร์ของผู้ใช้ไปยัง URL ที่ระบุโดย พารามิเตอร์
redirect_uri
ระบุรหัสการให้สิทธิ์ที่คุณ เพิ่งสร้าง และค่าสถานะเดิมที่ไม่มีการแก้ไขเมื่อคุณเปลี่ยนเส้นทาง ด้วยการเพิ่มพารามิเตอร์code
และstate
ต่อท้าย ตัวอย่างมีดังต่อไปนี้ ของ URL ผลลัพธ์:https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID?code=AUTHORIZATION_CODE&state=STATE_STRING
จัดการคำขอแลกเปลี่ยนโทเค็น
ปลายทางการแลกเปลี่ยนโทเค็นของบริการมีโทเค็น 2 ประเภท การแลกเปลี่ยน:
- แลกเปลี่ยนรหัสการให้สิทธิ์สำหรับโทเค็นเพื่อการเข้าถึงและโทเค็นการรีเฟรช
- แลกเปลี่ยนโทเค็นการรีเฟรชสำหรับโทเค็นเพื่อการเข้าถึง
คำขอแลกเปลี่ยนโทเค็นมีพารามิเตอร์ต่อไปนี้
พารามิเตอร์ปลายทางของการแลกเปลี่ยนโทเค็น | |
---|---|
client_id |
สตริงที่ระบุต้นทางของคำขอเป็น Google สตริงนี้ต้อง ได้รับการลงทะเบียนในระบบของคุณเป็นตัวระบุที่ไม่ซ้ำกันของ Google |
client_secret |
สตริงลับที่คุณลงทะเบียนกับ Google สําหรับบริการของคุณ |
grant_type |
ประเภทของโทเค็นที่แลกเปลี่ยน อย่างใดอย่างหนึ่ง
authorization_code หรือ refresh_token |
code |
เมื่อ grant_type=authorization_code โค้ด Google
ที่ได้รับจากปลายทางการลงชื่อเข้าใช้หรือการแลกเปลี่ยนโทเค็น |
redirect_uri |
เมื่อ grant_type=authorization_code พารามิเตอร์นี้คือช่วง
URL ที่ใช้ในคำขอการให้สิทธิ์เริ่มต้น |
refresh_token |
เมื่อ grant_type=refresh_token โทเค็นการรีเฟรช Google
ที่ได้รับจากปลายทางการแลกเปลี่ยนโทเค็น |
แลกเปลี่ยนรหัสการให้สิทธิ์สำหรับโทเค็นเพื่อการเข้าถึงและโทเค็นการรีเฟรช
หลังจากผู้ใช้ลงชื่อเข้าใช้และอุปกรณ์ปลายทางของการให้สิทธิ์จะแสดงการให้สิทธิ์ที่มีอายุสั้น ไปยัง Google จากนั้น Google จะส่งคำขอไปยังปลายทางการแลกเปลี่ยนโทเค็นเพื่อแลกเปลี่ยน รหัสการให้สิทธิ์สำหรับโทเค็นเพื่อการเข้าถึงและโทเค็นการรีเฟรช
สำหรับคำขอเหล่านี้ ค่าของ grant_type
คือ authorization_code
และค่า
ของ code
คือค่าของรหัสการให้สิทธิ์ที่คุณให้ Google ไว้ก่อนหน้านี้
ต่อไปนี้เป็นตัวอย่างของคำขอแลกเปลี่ยนรหัสการให้สิทธิ์สำหรับ
โทเค็นเพื่อการเข้าถึงและโทเค็นการรีเฟรช
POST /token HTTP/1.1 Host: oauth2.example.com Content-Type: application/x-www-form-urlencoded client_id=GOOGLE_CLIENT_ID&client_secret=GOOGLE_CLIENT_SECRET&grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=REDIRECT_URI
หากต้องการแลกเปลี่ยนรหัสการให้สิทธิ์กับโทเค็นเพื่อการเข้าถึงและโทเค็นการรีเฟรช
ปลายทางการแลกเปลี่ยนโทเค็นตอบสนองต่อคำขอ POST
ที่ดำเนินการตามขั้นตอนต่อไปนี้
- ตรวจสอบว่า
client_id
ระบุต้นทางของคำขอเป็นต้นทางที่ได้รับอนุญาต และclient_secret
ตรงกับค่าที่คาดไว้ - โปรดตรวจสอบสิ่งต่อไปนี้
- รหัสการให้สิทธิ์ถูกต้องและไม่หมดอายุ และไคลเอ็นต์ รหัสที่ระบุในคำขอตรงกับรหัสไคลเอ็นต์ที่เชื่อมโยงกับ รหัสการให้สิทธิ์ของคุณ
- URL ที่ระบุโดยพารามิเตอร์
redirect_uri
เหมือนกัน กับค่าที่ใช้ในคำขอการให้สิทธิ์เริ่มต้น
- หากยืนยันเกณฑ์ข้างต้นทั้งหมดไม่ได้ ให้แสดงผล HTTP
400 ข้อผิดพลาด "คำขอไม่ถูกต้อง" ที่มี
{"error": "invalid_grant"}
เป็นเนื้อความ - หรือใช้รหัสผู้ใช้จากรหัสการให้สิทธิ์เพื่อสร้างการรีเฟรช และโทเค็นเพื่อการเข้าถึง โทเค็นเหล่านี้จะเป็นค่าสตริงใดก็ได้ แต่ต้อง เป็นตัวแทนของผู้ใช้และไคลเอ็นต์ที่ใช้โทเค็นโดยไม่ซ้ำกัน และจะต้องไม่ คาดเดาได้ สำหรับโทเค็นเพื่อการเข้าถึง ให้บันทึกเวลาหมดอายุของโทเค็นด้วย (โดยทั่วไปคือ 1 ชั่วโมงหลังจากคุณออกโทเค็น) โทเค็นการรีเฟรชไม่มีวันหมดอายุ
- แสดงผลออบเจ็กต์ JSON ต่อไปนี้ในส่วนเนื้อหาของการตอบกลับ HTTPS
{ "token_type": "Bearer", "access_token": "ACCESS_TOKEN", "refresh_token": "REFRESH_TOKEN", "expires_in": SECONDS_TO_EXPIRATION }
Google จะจัดเก็บโทเค็นเพื่อการเข้าถึงและโทเค็นการรีเฟรชให้กับผู้ใช้ แล้วบันทึก วันหมดอายุของโทเค็นเพื่อการเข้าถึง เมื่อโทเค็นเพื่อการเข้าถึงหมดอายุ Google จะใช้การรีเฟรช เพื่อรับโทเค็นเพื่อการเข้าถึงใหม่จากปลายทางการแลกเปลี่ยนโทเค็น
แลกเปลี่ยนโทเค็นการรีเฟรชสำหรับโทเค็นเพื่อการเข้าถึง
เมื่อโทเค็นเพื่อการเข้าถึงหมดอายุ Google จะส่งคำขอไปยังปลายทางการแลกเปลี่ยนโทเค็น เพื่อแลกเปลี่ยนโทเค็นการรีเฟรชกับโทเค็นเพื่อการเข้าถึงใหม่
สำหรับคำขอเหล่านี้ ค่าของ grant_type
คือ refresh_token
และค่า
ของ refresh_token
คือค่าของโทเค็นการรีเฟรชที่คุณให้สิทธิ์ Google ไว้ก่อนหน้านี้
ต่อไปนี้เป็นตัวอย่างของคำขอแลกเปลี่ยนโทเค็นการรีเฟรชสำหรับ
โทเค็นเพื่อการเข้าถึง:
POST /token HTTP/1.1 Host: oauth2.example.com Content-Type: application/x-www-form-urlencoded client_id=GOOGLE_CLIENT_ID&client_secret=GOOGLE_CLIENT_SECRET&grant_type=refresh_token&refresh_token=REFRESH_TOKEN
หากต้องการแลกเปลี่ยนโทเค็นการรีเฟรชกับโทเค็นเพื่อการเข้าถึง ให้กำหนดปลายทางการแลกเปลี่ยนโทเค็น
ตอบสนองต่อคำขอ POST
ที่ดำเนินการตามขั้นตอนต่อไปนี้
- ยืนยันว่า
client_id
ระบุที่มาของคำขอเป็น Google และclient_secret
ตรงกับที่คาดไว้ - ตรวจสอบว่าโทเค็นการรีเฟรชถูกต้อง และรหัสไคลเอ็นต์ที่ระบุใน คำขอตรงกับรหัสไคลเอ็นต์ที่เชื่อมโยงกับโทเค็นการรีเฟรช
- หากยืนยันเกณฑ์ข้างต้นทั้งหมดไม่ได้ ให้แสดงผล HTTP
400 ข้อผิดพลาด "คำขอไม่ถูกต้อง" ที่มี
{"error": "invalid_grant"}
เป็นเนื้อความ - หรือใช้รหัสผู้ใช้จากโทเค็นการรีเฟรชเพื่อสร้างการเข้าถึง โทเค็น โทเค็นเหล่านี้จะเป็นค่าสตริงใดก็ได้ แต่จะต้องไม่ซ้ำกัน ผู้ใช้และไคลเอ็นต์ที่ใช้โทเค็น โดยต้องคาดเดาไม่ได้ สำหรับโทเค็นเพื่อการเข้าถึง ให้บันทึกเวลาหมดอายุของโทเค็นด้วย (โดยทั่วไปคือ 1 ชั่วโมงหลังจากคุณออกโทเค็น)
- แสดงผลออบเจ็กต์ JSON ต่อไปนี้ในส่วนเนื้อหาของ HTTPS
การตอบกลับ:
{ "token_type": "Bearer", "access_token": "ACCESS_TOKEN", "expires_in": SECONDS_TO_EXPIRATION }
ออกแบบอินเทอร์เฟซผู้ใช้แบบเสียงสำหรับขั้นตอนการตรวจสอบสิทธิ์
ตรวจสอบว่าผู้ใช้ได้รับการยืนยันหรือไม่ และเริ่มขั้นตอนการลิงก์บัญชี
- เปิดโปรเจ็กต์ Actions Builder ในคอนโซล Actions
- สร้างฉากใหม่เพื่อเริ่มลิงก์บัญชีใน Action ของคุณ
- คลิกฉาก
- คลิกไอคอนเพิ่ม (+) เพื่อเพิ่มฉากใหม่
- ในโหมดที่สร้างขึ้นใหม่ ให้คลิกไอคอนเพิ่ม add สำหรับเงื่อนไข
- เพิ่มเงื่อนไขที่ตรวจสอบว่าผู้ใช้ที่เชื่อมโยงกับการสนทนาเป็นผู้ใช้ที่ได้รับการยืนยันหรือไม่ หากการตรวจสอบไม่สำเร็จ การดำเนินการของคุณจะไม่สามารถลิงก์บัญชีในระหว่างการสนทนา และควรกลับไปให้สิทธิ์เข้าถึงฟังก์ชันการทำงานที่ไม่จำเป็นต้องมีการลิงก์บัญชี
- ในช่อง
Enter new expression
ในส่วนเงื่อนไข ให้ป้อนตรรกะต่อไปนี้user.verificationStatus != "VERIFIED"
- ในส่วนการเปลี่ยน ให้เลือกฉากที่ไม่ต้องมีการลิงก์บัญชีหรือฉากที่เป็นจุดเข้าถึงฟังก์ชันการทำงานสำหรับผู้มาเยือนเท่านั้น
- ในช่อง
- คลิกไอคอนเพิ่ม add สำหรับเงื่อนไข
- เพิ่มเงื่อนไขเพื่อทริกเกอร์โฟลว์การลิงก์บัญชีหากผู้ใช้ไม่มีข้อมูลระบุตัวตนที่เชื่อมโยง
- ในช่อง
Enter new expression
ในส่วนเงื่อนไข ให้ป้อนตรรกะต่อไปนี้user.verificationStatus == "VERIFIED"
- ในส่วนการเปลี่ยน ให้เลือกโหมดระบบการลิงก์บัญชี
- คลิกบันทึก
- ในช่อง
เมื่อบันทึกแล้ว ระบบจะเพิ่มโหมดระบบการลิงก์บัญชีใหม่ที่ชื่อว่า <SceneName>_AccountLinking
ลงในโปรเจ็กต์
ปรับแต่งฉากการลิงก์บัญชี
- เลือกโหมดระบบการลิงก์บัญชีในส่วนฉาก
- คลิกส่งพรอมต์ แล้วเพิ่มประโยคสั้นๆ เพื่ออธิบายให้ผู้ใช้ทราบว่าทำไมการดำเนินการจึงจำเป็นต้องเข้าถึงข้อมูลประจำตัว (เช่น "เพื่อบันทึกค่ากำหนดของคุณ")
- คลิกบันทึก
- ในส่วนเงื่อนไข ให้คลิกหากผู้ใช้ลิงก์บัญชีสำเร็จแล้ว
- กำหนดค่าว่าขั้นตอนควรดำเนินการอย่างไรหากผู้ใช้ตกลงที่จะลิงก์บัญชี เช่น เรียกใช้เว็บฮุคเพื่อประมวลผลตรรกะทางธุรกิจที่กำหนดเองที่จำเป็น แล้วเปลี่ยนกลับไปยังฉากที่สร้างขึ้น
- คลิกบันทึก
- คลิกหากผู้ใช้ยกเลิกหรือปิดการลิงก์บัญชีในส่วนเงื่อนไข
- กำหนดค่าว่าขั้นตอนควรดำเนินการอย่างไรหากผู้ใช้ไม่ตกลงที่จะลิงก์บัญชี เช่น ส่งข้อความตอบรับและเปลี่ยนเส้นทางไปยังฉากที่มีฟังก์ชันการทำงานที่ไม่ต้องใช้การลิงก์บัญชี
- คลิกบันทึก
- ในส่วนเงื่อนไข ให้คลิกหากระบบหรือเครือข่ายเกิดข้อผิดพลาด
- กำหนดค่าว่าขั้นตอนควรดำเนินการอย่างไรหากดำเนินการลิงก์บัญชีไม่สำเร็จเนื่องจากข้อผิดพลาดของระบบหรือเครือข่าย เช่น ส่งข้อความตอบรับและเปลี่ยนเส้นทางไปยังฉากที่มีฟังก์ชันการทำงานที่ไม่ต้องใช้การลิงก์บัญชี
- คลิกบันทึก
จัดการคำขอเข้าถึงข้อมูล
หากคำขอ Assistant มีโทเค็นเพื่อการเข้าถึง ก่อนอื่นให้ตรวจสอบว่าโทเค็นเพื่อการเข้าถึงถูกต้อง (และยังไม่หมดอายุ) แล้วจึงเรียกข้อมูลบัญชีผู้ใช้ที่เชื่อมโยงจากฐานข้อมูล