มีเหตุผลใดบ้างที่ไม่ควรใช้ JSONP สำหรับคำขอ AJA~X?

ในฐานะที่เราเป็นนักพัฒนาเว็บ หนึ่งในเป้าหมายหลักของเราคือการทำให้แน่ใจว่าแอปพลิเคชันที่เราสร้างมีฟังก์ชันการทำงานที่สมบูรณ์ มีประสิทธิภาพ และปลอดภัย เมื่อเผชิญหน้ากับคำขอ AJAX เทคนิคทั่วไปที่มักจะถูกพูดถึงคือ JSONP (JSON with Padding) ซึ่งใช้กันอย่างแพร่หลายในการทำคำขอข้ามโดเมน โดย JSONP ใช้ประโยชน์จากความจริงที่ว่าแท็ก <script> สามารถโหลดเนื้อหาจากโดเมนใด ๆ ได้ อย่างไรก็ตาม มีเหตุผลใดบ้างที่จำเป็นต้องหลีกเลี่ยง JSONP โดยเฉพาะเมื่อคุณไม่มีการทำงานข้ามโดเมน?

ในโพสต์นี้ เราจะเจาะลึกถึงเหตุผลที่คุณอาจต้องคิดสองครั้งก่อนที่จะรวม JSONP เข้ากับแอป AJA~X ของคุณ

JSONP คืออะไร?

JSONP ย่อมาจาก JSON with Padding เป็นวิธีการที่ช่วยให้นักพัฒนาสามารถขอข้อมูลจากเซิร์ฟเวอร์ที่อยู่ในโดเมนที่แตกต่างจากแอปพลิเคชันของตน วิธีนี้ช่วยหลีกเลี่ยงนโยบายเดียวกันของต้นทางที่มีอยู่ในเว็บเบราว์เซอร์ ซึ่งจะบล็อกคำขอดังกล่าวมิฉะนั้น

นี่คือตัวอย่างง่ายๆ ของคำขอ JSONP อาจมีลักษณะดังนี้:

function handleResponse(data) {
    console.log(data);
}

let script = document.createElement('script');
script.src = 'https://example.com/data?callback=handleResponse';
document.body.appendChild(script);

ข้อเสียของการใช้ JSONP

แม้ว่าจะใช้งานง่ายและเป็นวิธีที่ชาญฉลาดในการหลีกเลี่ยงปัญหาข้ามโดเมน แต่ JSONP ก็ไม่ได้ปราศจากข้อเสีย ต่อไปนี้คือปัจจัยสำคัญหลายประการที่ต้องพิจารณา:

1. ขาดการจัดการข้อผิดพลาด

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

2. ช่องโหว่ด้านความปลอดภัย

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

3. พฤติกรรมของเบราว์เซอร์แตกต่างกัน

  • พฤติกรรมของแท็ก <script> ที่สร้างขึ้นแบบไดนามิกอาจแตกต่างกันไปในแต่ละเบราว์เซอร์ คุณอาจพบผลลัพธ์ที่ไม่คาดคิดได้ขึ้นอยู่กับทางเลือกของเบราว์เซอร์ของผู้ใช้

4. ความยืดหยุ่นที่จำกัด

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

5. ความยากในการดีบัก

  • การดีบักปัญหาที่เกิดจาก JSONP มักจะยากกว่าปกติ เนื่องจากข้อผิดพลาดไม่ถูกส่งกลับเหมือนกับคำขอ AJAX แบบดั้งเดิม

สรุป

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

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

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