Migrate to Google Sign-In before 2023

บันทึกการปรับโปรแกรม เพื่อรองการใช้งาน Google Sign-In ตามคำแนะนำล่าสุด
 
ประมาณเดือนมีนาคม 2022 มีอีเมลจาก Google แจ้งว่าจะเลิกใช้โค้ด Sign-In จาก library เดิม และเปลี่ยนไปใช้ Google Identity Services SDK แทน มีกำหนดเวลาภายในปีหน้า เป็นเวลา 9 เดือน นับตั้งแต่วันแรกที่ได้รับแจ้ง เรื่องนี้ผุดมารบกวนจิตใจเป็นระยะ เพราะว่ายังประเมินขอบเขตไม่ได้ว่าแค่ปรับแก้เล็กน้อย หรือต้องรื้อใหญ่ ที่สำคัญเดิมพันค่อนข้างสูง หากไม่ทันกำหนดผู้ใช้ทั้งหมดจะมีปัญหา เพราะโปรแกรมใช้งานต่อไม่ได้

แว๊บแรกที่นึกในใจ เหนื่อยอีกแล้ว โปรแกรมของเราเดินทางมายาวนานเกือบสิบปี จะเรียกว่าเข้าสู่ช่วงผู้สูงวัย Legacy Code ผ่านการปรับปรุงต่อเติม มีทั้งงานประนีตและตัดปะตลอดระยะเวลาที่ผ่านมา จนมีความซับซ้อนผสมยุ่งเหยิง มีงานหลายส่วนเชื่อมโยงกับ Google Services เช่น Drive API, Sheets API, Calendar API จำเป็นต้องกลับไปรีวิวโค้ดเหล่านั้น

เบื้องต้น หลังจากพยายามทำความเข้าใจกับเนื้อหาคำแนะนำตาม link ที่ให้มา (เนื้อหา ณ วันนั้น แตกต่างจากปัจจุบัน) สรุปง่าย ๆ คือ อ่านแล้วเต็มไปด้วยคำถามในใจเต็มไปหมด ไม่แน่ใจว่าต้องทำอะไรบ้าง แค่ไหนพอ ทำกับไม่ทำจะเกิดอะไรแตกต่างจากเดิมบ้าง และที่สำคัญตรวจสอบได้อย่างไร เลือกประเด็นที่แก้โค้ดน้อยและเสี่ยงน้อยที่สุด ตรงที่เปลี่ยน library เป็น gsi/client ก่อน ทดสอบดูว่าโปรแกรมยังทำงานได้เหมือนเดิมตามที่บอกหรือไม่

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

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

Implicit Flow

โค้ดเดิมในโปรแกรม ทำตามคำแนะนำ oauth2 flow ผ่าน library เดิม ในคำแนะนำใหม่บอกว่ามี 2 วิธี Implicit Flow กับ Authorization Code Flow เมื่อเทียบข้อแตกต่างดูแล้ว ทำให้ต้องวางยุทธศาสตร์เป็น 2 ระยะ

ผ่าตัดเล็กก่อนด้วย Implicit Flow ไม่ต้องมี Backend Platform, Secure Storage และ Authorization Endpoint สามารถทดลองปรับโปรแกรมได้เร็วและง่ายกว่า
หากทำได้แล้ว ค่อยพิจารณาความจำเป็นอีกทีว่าต้องรื้อให้เป็น Code Flow หรือไม่ เพราะดูแล้วน่าจะเป็นงานใหญ่

จากการทดสอบ Implicit Flow มีผลกระทบเกิดขึ้น ทุกครั้งที่เปิดแท็บใหม่ ขั้นตอน authorize จะเปิดหน้าต่าง Consent เพื่อรอ Sign-In ไม่สามารถทำแบบเงียบ ๆ ให้ผ่านอัตโนมัติ (Immediate Sign-In) แบบเดิมได้
กูเกิ้ลบอกว่าเป็นเหตุผลด้านความปลอดภัย จึงไม่ยินยอมให้ทำ Immediate Sign-In โดยไม่มีการแสดงให้ผู้ใช้รับรู้

> Due to security concerns, only the popup UX is support.

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

Existing Client IDs

> By default, newly created Client IDs are now blocked from using the older Platform Library, existing Client IDs are unaffected.

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

ดาเจตนาของกูเกิ้ล น่าจะมีโปรแกรมเก่าที่แก้ไขไม่ทัน จึงผ่อนปรนเงื่อนเวลาบังคับใช้ไปก่อน อาจจะแค่ชั่วคราว หรือปล่อยไปเรื่อย ๆ จนกว่าโปรแกรมเหล่านั้นจะเลิกใช้ไปเอง อย่างน้อยก็รู้สึกโล่งใจขึ้นอีกหน่อย สถานการณ์ไม่ถึงกับคับขัน แต่ก็วางใจไม่ได้
ปล่อยวางไปประมาณ 3 เดือน จนกระทั่งเดือน กันยายน 2022 ได้รับอีเมลเตือนอีกครั้ง ทำให้กลับมาคิดได้ว่าไม่ควรเสี่ยงวางใจกับข้อผ่อนปรน โดยไม่ได้ทำอะไรเลย แต่กว่าจะเคลียร์เวลาให้กลับมาโฟกัสเรื่องนี้ได้ต้องใช้เวลา
รอจนกลับมามีสมาธิอีกครั้ง แล้วพบเรื่องที่ไม่เคลียร์และอ่านข้ามไปครั้งก่อน ระหว่าง Existing Client IDs กับ New Client IDs ที่กล่าวถึงในประโยคที่ต่อเนื่องกัน บอกว่าหากต้องการใช้ Sign In วิธีเก่าต้องตั้งค่า plugin_name ด้วย

> New Client IDs created before July 29th, 2022 can set plugin_name to enable use of the Google Platform Library.

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

Prompt & Hint

ธันวาคม 2022 ถึงแม้ว่าจะจัดการตามที่เล่าไปแล้ว ตั้งใจว่าเดือนนี้พยายามกลับมาโฟกัสให้ได้มากที่สุด มีความบังเอิญเกิดขึ้น ที่ทำให้งานเฟสแรกเสร็จเร็วกว่าคาด
เรื่องบังเอิญมีอยู่ว่า วันหนึ่งผมเอาโน๊ตบุ๊คสำรองมาใช้ ทดลองเรียกโปรแกรมใช้โค้ด Sign-In ที่แก้ค้างไว้มาทบทวนใหม่ แล้วพบว่าสามารถเปิดแท็บใหม่ไม่ต้องหยุดรอ Consent เพื่อ Sign-In ก่อนทุกครั้ง
โดยไม่ได้แก้ไขอะไร โค้ดกลับมาใช้ได้ตามที่ต้องการ เข้าใจว่ากูเกิ้ลเองก็คงปรับปรุง library ด้วย วันนั้นสามารถเดินหน้าเก็บงานปรับโค้ดส่วนที่เหลือจนคืบหน้าไปมาก

เมื่อเอาโค้ดกลับมาเรียกในเครื่องที่เคยทดสอบตั้งแต่แรก ปรากฏว่ายังมีอาการเดิม หยุดรอ Consent ทุกครั้งที่เปิดแท็บใหม่
อ้างอิงตามคำอธิบาย กลไกในการ Sign-In ใหม่ ทำงานผ่าน initTokenClient และ requestAccessToken ส่ง parameter prompt เป็น empty string เพื่อไม่ต้องหยุดรอถาม Consent นอกจากตอน Sign-In ครั้งแรก

การทดสอบในโน๊ตบุ๊คสำรองก็เป็นตามนั้น แต่อีกเครื่องกลับไม่เป็นเช่นนั้น ข้อแตกต่างระหว่างเครื่องทั้งสองอยู่ที่ จำนวน Account ที่แตกต่างกัน เครื่องที่มีมากกว่า 1 Account ไม่สามารถ Sign-In อัตโนมัติได้ ต้องรอให้เลือกว่าจะใช้ Account ไหนทุกครั้ง เมื่อเดาสาเหตุได้แล้วก็ไม่ยาก ปรับโปรแกรมให้จำ Account ของผู้ใช้ที่ Sign-In ครั้งหลังสุด แล้วส่งผ่าน parameter hint คู่กับ prompt ทำให้ไม่ต้องหยุดรอให้เลือก Account อีก

สรุป
 
การปรับปรุงโปรแกรมจาก Immediate Sign-In ตาม library เดิม เปลี่ยนเป็นใช้ Access Token ตาม library ใหม่ เสร็จเร็วกว่าคาด จากการทดสอบมีความเปลี่ยนแปลงจากเดิมอยู่ 2 เรื่อง ด้วยเหตุผลทางด้านความปลอดภัย เมื่อเปิดแท็บใหม่จะมี popup โผล่ขึ้นมาแว๊บนึง รู้สึกรบกวนสำหรับบางคน แต่นั่นเป็นเจตนาของกูเกิ้ลเพื่อแสดงให้รู้ว่า โปรแกรมมีการใช้ Google Sign-In อีกเรื่องหนึ่งที่เจอ ไม่สามารถแช่ Account ไว้นาน ๆ Access Token มีอายุ 1 ชั่วโมง หมายความว่าหากไม่ได้ใช้งานต่อเนื่อง หลังจาก 1 ชั่วโมงไปแล้วเมื่อกลับไปใช้โปรแกรมจะต้อง Sign-In ใหม่
  
หลังจากนี้น่าจะมีเวลาทดสอบ ทำความเข้าใจ และวางแผนปรับปรุงขั้นต่อไป โชคดีที่ผ่านพ้นความกดดันปี 2022 ไปได้ ด้วยความบังเอิญ