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

และทุกอย่างเริ่มต้นขึ้นเมื่อวันหนึ่งข้อความนี้ปรากฏบนผนังของฉัน:


ด้วยความอยากรู้อยากเห็น ฉันจึงคลิกลิงก์ไปและไปอยู่ที่ไซต์ฟิชชิ่งอื่น แต่ลิงก์นั้นดูแปลกสำหรับฉันดูเหมือนว่า (ครึ่งหนึ่งของอักขระใน ASCII):
vkontakte.ru/away.php ? ถึง=http%3A%2F%2FApi.vKontakte.Ru%2F%2Fo%2561u%2574%…

นี่คือจุดเริ่มต้นของความสนุก...

ลองดูลิงค์ที่สองในส่วนต่างๆ:

แต่ละพารามิเตอร์หมายถึงอะไร:

• client_id - ID ของแอปพลิเคชันที่ต้องมีการอนุญาต
• เปลี่ยนเส้นทาง_uri - ที่อยู่ที่จะส่ง access_token (ผ่านการเปลี่ยนเส้นทาง)
• จอแสดงผล - ประเภทของหน้าต่างการอนุญาต (เพจ ป๊อปอัป สัมผัส และ wap)

จริงๆ แล้ว เปลี่ยนเส้นทาง_uri มีที่อยู่ของไซต์ฟิชชิ่ง เนื่องจากมีข้อผิดพลาดในพารามิเตอร์การแสดงผล (มีขยะ “?390852”) หน้าต่างการอนุญาตจึงไม่แสดง แต่ถูกเปลี่ยนเส้นทางไปยังไซต์ฟิชชิ่งทันทีด้วยพารามิเตอร์ต่อไปนี้: error=invalid_request&error_description=Invalid+display+passed

นี่คือจุดรวมของการข้ามบัญชีดำของไซต์ VKontakte ที่เป็นอันตราย มีเพียงการแจ้งเตือนเกี่ยวกับการเปลี่ยนไปใช้ api.vk.com เท่านั้นที่ปรากฏขึ้น และจากการเปลี่ยนแปลงนี้ เราตรงไปยังไซต์ฟิชชิ่งที่อยู่ในบัญชีดำ เมื่อคุณไปที่ลิงก์ vkontakte.ru/away.php?to=vgostivk.dyndns**:

ปรากฎว่าแอปพลิเคชันที่ต้องมีการอนุญาตค้างอยู่กับผู้ใช้ที่ถูกแฮ็ก:

และไซต์ฟิชชิ่งเองก็ได้รับการออกแบบมาค่อนข้างน่าสนใจ การออกแบบเป็นไปตามปกติและเป็นสไตล์การติดต่อและขอให้เข้าสู่ระบบ ฉันเข้าสู่ระบบโดยใช้อีเมลและรหัสผ่านแบบสุ่มและฉันก็กลืนอีเมลปลอมเข้าไปได้ สิ่งที่เกิดขึ้นต่อไปนั้นน่าสนใจยิ่งขึ้น ข่าวจาก “Pavel Durov” ปรากฏบนหน้าหลัก:

หลังจากคลิกที่ปุ่ม "สร้างตัวนับส่วนตัว" แถบความคืบหน้าอันยอดเยี่ยมก็ตามมา จากนั้นระบบจะขอให้คุณระบุหมายเลขของคุณและส่ง SMS:

ตามทฤษฎีแล้ว หลังจาก "เปิดใช้งาน" สำเร็จแล้ว มันควรจะเปลี่ยนเส้นทางไปที่หน้า activ.php แต่ฉันไม่สามารถไปที่นั่นได้ ข้อความที่ตัดตอนมาจากสคริปต์ JS ของไซต์ฟิชชิ่ง:

...
ถ้า (req.status == 200) (
// หากสถานะเป็น 200 (ตกลง) - ให้ตอบกลับผู้ใช้
ถ้า (req.responseText == "ตกลง" ) (
//statusElem.innerHTML = "ทุกอย่างกำลังคึกคัก!";
get_activation();
}
ถ้า (req.responseText == "ไม่" ) (statusElem.innerHTML = "รหัสเปิดใช้งานไม่ถูกต้อง";}
//statusElem.innerHTML = "การตอบสนองของเซิร์ฟเวอร์: "+req.responseText;
...
ฟังก์ชั่น get_activation() (
เอกสาร .location="activ.php" ;
}

* ซอร์สโค้ดนี้ถูกเน้นด้วย Source Code Highlighter

บรรทัดล่าง: ผู้ฉ้อโกงใช้ OAuth 2.0 เพื่อเลี่ยงผ่านคำเตือน รับรหัสผ่านและอีเมลของผู้ใช้ และแม้แต่พยายามฉ้อโกง กำลังส่ง SMS(ส่วนใหญ่จะใช้ระบบสมัครสมาชิก)

1. การเปิดเบราว์เซอร์ในตัวด้วยหน้าเข้าสู่ระบบ
2. ผู้ใช้จะถูกขอให้ยืนยันว่าได้รับสิทธิ์แล้ว
3. หากผู้ใช้เห็นด้วย เบราว์เซอร์จะถูกเปลี่ยนเส้นทางไปยังหน้าต้นขั้วในส่วน (หลัง #) ซึ่งมีการเพิ่ม URL โทเค็นการเข้าถึง
4. แอปพลิเคชันสกัดกั้นการเปลี่ยนเส้นทางและรับ โทเค็นการเข้าถึงจากที่อยู่เพจ

ตัวเลือกนี้จำเป็นต้องเพิ่มหน้าต่างเบราว์เซอร์ในแอปพลิเคชัน แต่ไม่จำเป็นต้องมีส่วนของเซิร์ฟเวอร์และ โทรเพิ่มเติมเซิร์ฟเวอร์ต่อเซิร์ฟเวอร์เพื่อการแลกเปลี่ยน รหัสการอนุญาตบน โทเค็นการเข้าถึง.

ตัวอย่าง

เปิดเบราว์เซอร์ด้วยหน้าเข้าสู่ระบบ:
> GET /oauth/authorize?response_type=token&client_id=464119 HTTP/1.1 > โฮสต์: Connect.mail.ru

หลังจากที่ผู้ใช้ให้สิทธิ์ การเปลี่ยนเส้นทางจะเกิดขึ้นไปยังหน้าต้นขั้วมาตรฐาน สำหรับ Mail.Ru นี่คือ Connect.mail.ru/oauth/success.html:
< HTTP/1.1 302 Found < Location: http://connect.mail.ru/oauth/success.html#access_token=FJQbwq9&token_type=bearer& expires_in=86400&refresh_token=yaeFa0gu

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

การอนุญาตโดยการเข้าสู่ระบบและรหัสผ่าน

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

ตัวอย่าง

> POST /oauth/token HTTP/1.1 > โฮสต์: Connect.mail.ru > ประเภทเนื้อหา: application/x-www-form-urlencoded > > grant_type=password&client_id=31337&client_secret=deadbeef&username=api@corp.mail.ru&password= qwerty< HTTP/1.1 200 OK < Content-Type: application/json < < { < "access_token":"SlAV32hkKG", < "token_type":"bearer", < "expires_in":86400, < "refresh_token":"8xLOxBtZp8", < }
คำอธิบายในข้อกำหนด

การเรียกคืนการอนุญาตก่อนหน้านี้

โดยปกติ, โทเค็นการเข้าถึงมีอายุการเก็บรักษาที่จำกัด สิ่งนี้อาจมีประโยชน์ เช่น หากมีการส่งข้อมูลผ่าน ช่องเปิด- เพื่อหลีกเลี่ยงการบังคับให้ผู้ใช้เข้าสู่ระบบหลังจากหมดอายุ โทเค็นการเข้าถึง"และในตัวเลือกทั้งหมดข้างต้น นอกเหนือจากนั้น โทเค็นการเข้าถึง“อาจจะกลับมาอีกครั้ง. โทเค็นการรีเฟรช- คุณสามารถใช้มันเพื่อรับ โทเค็นการเข้าถึงใช้คำขอ HTTP ซึ่งคล้ายกับการอนุญาตโดยใช้ข้อมูลเข้าสู่ระบบและรหัสผ่าน

ตัวอย่าง

> POST /oauth/token HTTP/1.1 > โฮสต์: Connect.mail.ru > ประเภทเนื้อหา: application/x-www-form-urlencoded > > grant_type=refresh_token&client_id=31337&client_secret=deadbeef&refresh_token=8xLOxBtZp8< HTTP/1.1 200 OK < Content-Type: application/json < < { < "access_token":"Uu8oor1i", < "token_type":"bearer", < "expires_in":86400, < "refresh_token":"ohWo1ohr", < }

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

การสร้างข้อมูลรับรอง OAuth2

หากต้องการสร้างข้อมูลรับรอง OAuth2 ให้ทำตามขั้นตอนด้านล่าง

การกำหนดประเภทแอปพลิเคชัน

ก่อนอื่นคุณต้องพิจารณาก่อน ประเภทแอปพลิเคชันที่คุณต้องการสร้าง มีแอปพลิเคชันสองประเภทใน AdWords API:

• แอปพลิเคชันที่ติดตั้งได้(ที่แนะนำ);
• แอปพลิเคชันเว็บ

ใช้ตารางด้านล่างกำหนด ประเภทที่ต้องการการใช้งาน

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

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

การสร้างรหัสลูกค้าและรหัสลับ

เมื่อคุณกำหนดประเภทการสมัครของคุณแล้ว ให้คลิกที่แท็บที่เหมาะสมด้านล่างแล้วทำตามคำแนะนำเพื่อสร้าง ID และ รหัสลับลูกค้า.

แอพพลิเคชั่นที่ติดตั้งได้

1. เปิด
2. สร้างโครงการ สร้าง.
3. สร้างข้อมูลรับรองและจากนั้น - รหัสไคลเอ็นต์ OAuth.
4. บันทึก
5. ในส่วน ประเภทการสมัครเลือก ประเภทอื่นๆและให้ข้อมูลที่จำเป็น
6. คลิก สร้าง.
7. ตัวระบุและ รหัสลับ

แอปพลิเคชันเว็บ

1. เปิด
2. จากเมนูแบบเลื่อนลงโครงการ ให้เลือก สร้างโครงการจากนั้นระบุชื่อโปรเจ็กต์และเปลี่ยน ID หากจำเป็น จากนั้นคลิกปุ่ม สร้าง.
3. บนหน้าข้อมูลประจำตัว เลือก สร้างข้อมูลรับรองและจากนั้น - รหัสไคลเอ็นต์ OAuth.
4. คุณอาจถูกขอให้ระบุชื่อผลิตภัณฑ์ ในกรณีนี้ คลิก ปรับแต่งหน้าต่างคำขอการเข้าถึงป้อนข้อมูลที่ต้องการแล้วคลิก บันทึกเพื่อกลับไปยังหน้าจอข้อมูลรับรอง
5. ในส่วน ประเภทการสมัครเลือก แอปพลิเคชันเว็บ- ปฏิบัติตามคำแนะนำเพื่อระบุแหล่งที่มาของ JavaScript และ/หรือเปลี่ยนเส้นทาง URI
6. คลิก สร้าง.
7. บนหน้าที่ปรากฏขึ้น ให้คัดลอก ตัวระบุและ รหัสลับลูกค้า - คุณจะต้องใช้เมื่อตั้งค่าไลบรารีไคลเอนต์

ทำตามคำแนะนำด้านล่างเพื่อกำหนดค่าการใช้ข้อมูลรับรอง OAuth2 กับไลบรารีไคลเอ็นต์ของภาษาของคุณ

บันทึก.หากคุณเลือกที่จะไม่ใช้หนึ่งในไลบรารีไคลเอนต์ของเรา คุณจะต้องดำเนินการตามกระบวนการเพื่อตัวคุณเอง

สนามเด็กเล่น OAuth2

ตัวเลือกอื่นสำหรับการสร้างข้อมูลรับรอง OAuth2 คือการใช้ สนามเด็กเล่น OAuth2- เมื่อใช้ร่วมกับคอนโซล Google API ระบบนี้จะช่วยให้คุณสร้างโทเค็น OAuth2 ได้ด้วยตัวเอง

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

การตั้งค่า

คำเตือน.หากต้องการใช้ สนามเด็กเล่น OAuth2คุณต้องสร้าง รหัสลูกค้าสำหรับ . นี้ คนเดียวเท่านั้นแอปพลิเคชันประเภทหนึ่งที่ใช้ได้กับ OAuth2 Playground อ่านเพิ่มเติมในส่วนด้านบน

วิธีรับรหัสลูกค้าและรหัสลับ

1. เปิด
2. เลือกโปรเจ็กต์ที่มีอยู่จากเมนูแบบเลื่อนลงหรือสร้างโปรเจ็กต์ใหม่
3. บนหน้าข้อมูลประจำตัว เลือก สร้างข้อมูลรับรองและจากนั้น - รหัสไคลเอ็นต์ OAuth.
4. ในส่วน ประเภทการสมัครเลือก แอปพลิเคชันเว็บ.
5. ในส่วนเพิ่ม บรรทัดถัดไป: https://site/oauthplayground
6. คลิก สร้าง.
7. เขียนมันลงไป ตัวระบุและ รหัสลับลูกค้าที่ระบุในหน้าที่ปรากฏขึ้น

คุณจะต้องใช้มันในขั้นตอนถัดไป

คำเตือน.วิธีการสร้างโทเค็น จากอะไรบัญชีกูเกิล

คุณได้ลงชื่อเข้าใช้เบราว์เซอร์ของคุณ ขึ้นอยู่กับบัญชี AdWords ที่คุณสามารถเข้าถึงได้โดยใช้ข้อมูลรับรอง OAuth2 ที่คุณสร้าง อาจเป็นการดีกว่าถ้าทำตามขั้นตอนเหล่านี้ในโหมดไม่ระบุตัวตนหรือไม่ต้องลงชื่อเข้าใช้บัญชี Google ของคุณ มีแนวโน้มว่าคุณจะต้องใช้ข้อมูลประจำตัวที่แตกต่างจากบัญชีที่คุณอยู่เมื่อคุณได้รับรหัสลูกค้าและรหัสลับ

วิธีลบ OAuth2 Playground ออกจาก Client ID เนื่องจากคุณมีอยู่แล้วคุณไม่จำเป็นต้องใช้ OAuth2 Playground เป็น URI การเปลี่ยนเส้นทางที่แก้ไขแล้วอีกต่อไป หากต้องการลบระบบนี้ออกจากรายการ ให้ทำตามขั้นตอนเหล่านี้:

1. ไปที่.
2. เลือกโครงการของคุณจากเมนูแบบเลื่อนลง
3. ในหน้าข้อมูลรับรอง เลือกชื่อของรหัสไคลเอ็นต์
4. ลบ https://site/oauthplayground ออกจากฟิลด์ URI การเปลี่ยนเส้นทางที่อนุญาต- โปรดทราบว่าคุณต้องออกไปอย่างน้อยที่สุด หนึ่งเปลี่ยนเส้นทาง URI
5. คลิก บันทึก.

ดังนั้นคุณจึงมีข้อมูลประจำตัว OAuth ของคุณ ตอนนี้คุณสามารถสืบค้น AdWords API และใช้กับไลบรารีไคลเอ็นต์ที่จำเป็นได้แล้ว

บัญชีบริการ OAuth2

ส่วนนี้อธิบายวิธีเข้าถึง AdWords API โดยใช้บัญชีบริการ

บัญชีบริการคือบัญชีที่เป็นของแอปพลิเคชัน ไม่ใช่บัญชีแยกต่างหาก ผู้ใช้ปลายทาง- บัญชีบริการให้การโต้ตอบระหว่างเว็บแอปพลิเคชันและบริการของ Google แอปพลิเคชันของคุณเรียกใช้ API ในนามของบัญชีบริการโดยไม่เกี่ยวข้องกับผู้ใช้โดยตรง

AdWords API อนุญาตให้เข้าถึงบัญชีบริการข้ามโดเมน G Suite

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

การใช้บัญชีบริการมีข้อดีที่สำคัญสองประการ:

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

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

ทางเลือกแทนบัญชีบริการ

บัญชีบริการมีการใช้กันอย่างแพร่หลายในการให้บริการ การเข้าถึงซอฟต์แวร์ไปยัง API ผ่านโปรโตคอล OAuth2 โดยที่ผู้ใช้ไม่ต้องดำเนินการใดๆ

อย่างไรก็ตาม การตั้งค่าบัญชีดังกล่าวให้ทำงานกับ AdWords API ไม่ใช่เรื่องง่าย ทางเลือกที่ง่ายกว่ามีโทเค็นการรีเฟรชที่คงอยู่ วิธีการนี้ทำให้แอปพลิเคชันสามารถขอโทเค็นการเข้าถึงใหม่ได้ตลอดเวลา

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

ความต้องการ

• โดเมน G Suite ที่คุณเป็นเจ้าของ เช่น mydomain.com หรือ mybusiness.com
• โทเค็นนักพัฒนา AdWords API และควรเป็นบัญชีทดสอบ
• สำหรับภาษาที่ใช้

การตั้งค่าการเข้าถึงสำหรับบัญชีลูกค้า

ขั้นแรก คุณต้องสร้างคีย์บัญชีบริการในคอนโซล Google API

1. ลงชื่อเข้าใช้บัญชี G Suite ของคุณ เปิด .
2. จากเมนูแบบเลื่อนลงโครงการ ให้เลือก สร้างโครงการจากนั้นให้ข้อมูลที่จำเป็นแล้วคลิกปุ่ม สร้าง. โครงการใหม่จะปรากฏในรายการที่ใช้งานอยู่
3. ในเมนูด้านซ้าย มุมบนเลือก IAM และการบริหารและจากนั้น - บัญชีบริการในเมนูด้านซ้าย
4. คลิก สร้างบัญชีบริการที่ด้านบนของหน้า
5. ป้อนชื่อบัญชีบริการ
6. ทำเครื่องหมายในช่อง สร้างใหม่ รหัสส่วนตัว และเลือกประเภทคีย์ JSON
7. ทำเครื่องหมายในช่อง เปิดใช้การมอบหมายการเข้าถึงข้อมูลในโดเมน G Suite ของคุณและระบุชื่อผลิตภัณฑ์สำหรับหน้าต่างคำขอเข้าถึง
8. คลิก สร้าง- ไฟล์คีย์ JSON จะเริ่มดาวน์โหลด บันทึกไฟล์ไว้ในที่ปลอดภัยซึ่งมีเพียงคุณเท่านั้นที่สามารถเข้าถึงได้
9. บนหน้า บัญชีบริการบัญชีบริการใหม่จะปรากฏขึ้น

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

ปัญหาด้านความปลอดภัย

เนื่องจาก G Suite ได้รับการจัดการในระดับโดเมน คุณจะต้องปกป้องไฟล์คีย์อย่างปลอดภัยซึ่งอนุญาตให้บัญชีที่ได้รับอนุญาตเข้าถึงได้ บริการของ Google- สิ่งนี้สำคัญอย่างยิ่งเนื่องจากเราให้บัญชีบริการที่สามารถปลอมตัวเป็นผู้ใช้โดเมนได้

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

วิธีการจัดให้มีความสามารถในการเลียนแบบ

หากต้องการให้ความสามารถในการเลียนแบบบัญชีบริการ ให้ทำตามขั้นตอนเหล่านี้:

ตอนนี้คุณสามารถเข้าถึงบัญชี AdWords ของคุณโดยใช้บัญชีบริการของคุณซึ่งเป็นส่วนหนึ่งของกระบวนการอนุมัติ OAuth2

การตั้งค่าไลบรารีไคลเอ็นต์

เลือกภาษาเพื่อดูคำแนะนำในการตั้งค่าไลบรารีไคลเอ็นต์

บันทึก.หากคุณเลือกที่จะไม่ใช้หนึ่งในไลบรารีไคลเอนต์ของเรา คุณจะต้องดำเนินการตามกระบวนการด้วยตนเอง

การเพิ่มประสิทธิภาพคำขอ OAuth2

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

ส่วนนี้อธิบายวิธีเพิ่มประสิทธิภาพการจัดการข้อมูลรับรอง OAuth2 เพื่อให้แอปพลิเคชันของคุณโต้ตอบกับ AdWords API ได้อย่างมีประสิทธิภาพมากขึ้น

ความสนใจ!ภายใต้เงื่อนไข ข้อมูลรับรองซึ่งหมายถึงชุดแอตทริบิวต์ข้อมูลรับรอง OAuth2 ทั้งชุด รวมถึงโทเค็นการเข้าถึงและวันหมดอายุ

กลยุทธ์การกระจายข้อมูลรับรอง

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

กลยุทธ์การกระจายข้อมูลรับรองขึ้นอยู่กับการออกแบบแอปพลิเคชัน

ในแอปพลิเคชันแบบมัลติเธรด คุณต้องใช้ข้อมูลประจำตัวเดียวกันสำหรับเซสชันของแต่ละเธรด

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

ในแอปพลิเคชันที่มีทั้งแบบหลายกระบวนการ/แบบกระจายและแบบมัลติเธรด แต่ละกระบวนการจำเป็นต้องรวมทั้งสองกลยุทธ์เข้าด้วยกัน

ต่อไปนี้เป็นกลยุทธ์ในการตรวจสอบสิทธิ์บัญชี AdWords บัญชีเดียว เช่น บัญชีผู้จัดการระดับบนสุดในลำดับชั้น

จากนั้นจะอธิบายวิธีการปรับกลยุทธ์เหล่านี้สำหรับ

แอปพลิเคชั่นแบบมัลติเธรด

ในแอปพลิเคชันแบบมัลติเธรด ข้อมูลรับรองต้องพร้อมใช้งานสำหรับเธรดที่แตกต่างกัน การอัปเดตข้อมูลรับรองจะต้องดำเนินการพร้อมกันเพื่อหลีกเลี่ยงสภาพการแข่งขัน

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

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

ตัวอย่างเช่น ในไลบรารีไคลเอ็นต์ Java คุณจะสร้างคลาส Singleton Credential และใช้สำหรับเซสชันทั้งหมด

แอพพลิเคชั่นแบบหลายกระบวนการและแบบกระจาย

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

ตัวอย่างเช่น งานหรือบริการเดียวอาจอัปเดตข้อมูลประจำตัวเป็นระยะๆ และพุชไปยังที่เก็บข้อมูลซึ่งเซิร์ฟเวอร์ต่างๆ จะใช้งานข้อมูลเหล่านั้น

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

อัปเดตงาน

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

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

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

การจัดเก็บข้อมูล

ที่เก็บข้อมูลใช้เพื่อให้ข้อมูลประจำตัว กระบวนการที่แตกต่างกันและเซิร์ฟเวอร์

ในการดำเนินการนี้ คุณสามารถใช้คลังข้อมูลที่มีอยู่หรือสร้างคลังข้อมูลเฉพาะเพื่อให้เซิร์ฟเวอร์รับข้อมูลประจำตัวได้ เช่น แนวทางแก้ไขที่เป็นไปได้คุณสามารถใช้เซิร์ฟเวอร์แคช (เช่น Memcached หรือ Infinispan) และที่เก็บข้อมูล NoSQL (เช่น MongoDB)

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

อย่าลืมรักษาข้อมูลรับรองของคุณให้ปลอดภัย

เมื่อบันทึกข้อมูลประจำตัว คุณต้องบันทึกคุณสมบัติ expiry_time ( เวลาปัจจุบัน+ expirs_in) และ Refresh_token พร้อมกับคุณสมบัติ access_token คุณสมบัติ expiry_time (วันที่หมดอายุของโทเค็น) คำนวณโดยใช้สูตรต่อไปนี้: เวลาคำขออัปเดต access_token + เวลาหมดอายุ_in (วันที่หมดอายุของโทเค็น)

พูลเซิร์ฟเวอร์

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

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

ใน กระบวนการแบบมัลติเธรดต้องใช้กลยุทธ์เดียวกันในการกระจายข้อมูลรับรองระหว่างเธรด

การรับรองความถูกต้องหลายบัญชี

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

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

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

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

OAuth2 ทำงานอย่างไร

บันทึก- AdWords API ยังไม่สนับสนุนการลงชื่อเข้าใช้พร้อมกันผ่านคำขอเข้าถึงข้อมูล (การออกแบบแบบไฮบริด) หรือการมอบอำนาจระดับโดเมน (2LO)

ขอบเขต

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

ด้านล่างนี้คือขอบเขตปัจจุบันและขอบเขตเดิมสำหรับ AdWords API

การเข้าถึงแบบออฟไลน์

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

แอปพลิเคชันที่ติดตั้งจะใช้การเข้าถึงแบบออฟไลน์ตามค่าเริ่มต้น

ส่วนหัวคำขอ HTTP

ส่วนหัว HTTP ในทุกคำขอที่ส่งไปยังเซิร์ฟเวอร์ AdWords API ต้องมีแบบฟอร์มต่อไปนี้:

การอนุญาต: ผู้ถือ THE_ACCESS_TOKEN

POST ... โฮสต์ HTTP/1.1: ... การอนุญาต: ผู้ถือ 1/fFAGRNJru1FTz70BzhT3Zg ประเภทเนื้อหา: text/xml;charset=UTF-8 ความยาวเนื้อหา: ... …

เข้าถึงและรีเฟรชโทเค็น

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

เมื่อโทเค็นการเข้าถึงหมดอายุ

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

เว้นแต่จะระบุไว้เป็นอย่างอื่น เนื้อหาของหน้านี้ได้รับอนุญาตภายใต้ใบอนุญาต Creative Commons Attribution 3.0 และตัวอย่างโค้ดได้รับอนุญาตภายใต้ใบอนุญาต Apache 2.0 สำหรับรายละเอียด โปรดดูของเรา Java เป็นเครื่องหมายการค้าจดทะเบียนของ Oracle และ/หรือบริษัทในเครือ

อัปเดตเมื่อวันที่ 24 กันยายน 2018