การประชุมเป็นการละเมิด RESTfulness จริง ๆ หรือไม่?

การใช้เซสชันใน RESTful API เป็นการละเมิด RESTfulness หรือไม่ ฉันได้เห็นความคิดเห็นมากมายไปในทิศทางใดทิศทางหนึ่ง แต่ฉันไม่มั่นใจว่าช่วงการประชุมนั้นสงบเงียบ จากมุมมองของฉัน:

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

ดังนั้นเซสชันจะละเมิดสิ่งนี้อย่างไร

• ฝั่งไคลเอ็นต์เซสชันจะรับรู้โดยใช้คุกกี้
• คุกกี้เป็นเพียงส่วนหัว HTTP พิเศษ
• คุกกี้เซสชันสามารถรับและเพิกถอนได้ตลอดเวลา
• คุกกี้เซสชั่นสามารถมีชีวิตที่ไม่มีที่สิ้นสุดถ้าจำเป็น
• รหัสเซสชัน (โทเค็นการตรวจสอบความถูกต้อง) ได้รับการตรวจสอบความถูกต้องของฝั่งเซิร์ฟเวอร์

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

สมมติฐานของฉันผิดหรือเปล่า? อะไรที่ทำให้เซสชันคุกกี้ไม่สงบ ?

ก่อนอื่นมานิยามคำศัพท์กัน:

• สงบ:

  สามารถระบุลักษณะการใช้งานที่สอดคล้องกับข้อ จำกัด REST ที่อธิบายไว้ในส่วนนี้ว่า "RESTful" [15] หากบริการละเมิดข้อ จำกัด ใด ๆ ที่จำเป็นจะไม่สามารถพิจารณาได้ว่า RESTful

  ตามวิกิพีเดีย

• ข้อ จำกัด ไร้สัญชาติ:

  ต่อไปเราจะเพิ่มข้อ จำกัด ในการโต้ตอบกับไคลเอนต์ - เซิร์ฟเวอร์: การสื่อสารจะต้องเป็นแบบไร้รัฐเช่นเดียวกับในรูปแบบของไคลเอนต์ - ไร้สัญชาติ - เซิร์ฟเวอร์ (CSS) ของส่วน 3.4.3 (รูปที่ 5-3) ดังนั้นแต่ละคำขอจากลูกค้า เซิร์ฟเวอร์จะต้องมีข้อมูลทั้งหมดที่จำเป็นในการทำความเข้าใจคำขอและไม่สามารถใช้ประโยชน์จากบริบทที่เก็บไว้บนเซิร์ฟเวอร์ สถานะเซสชันจะถูกเก็บไว้ทั้งหมดบนไคลเอนต์

  ตามวิทยานิพนธ์ฟีลดิง

ดังนั้นเซสชันฝั่งเซิร์ฟเวอร์จะละเมิดข้อ จำกัด ที่ไร้รัฐของ REST และ RESTfulness ก็เช่นกัน

คุกกี้เซสชันนั้นเหมือนกับกลไกการตรวจสอบความถูกต้อง HTTP ส่วนหัวอื่น ๆ ยกเว้นว่าจะใช้ส่วนหัวคุกกี้แทนการอนุญาตหรือส่วนหัวกรรมสิทธิ์อื่น ๆ

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

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

จากมุมมองของฉัน:

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

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

• รูปที่ 1 - การพิสูจน์ตัวตนไร้สัญชาติโดยไคลเอนต์ที่เชื่อถือได้

คุณอาจต้องการแคช auth ในหน่วยความจำในฝั่งเซิร์ฟเวอร์เพื่อให้เร็วขึ้นเนื่องจากคุณต้องตรวจสอบสิทธิ์ทุกคำขอ

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

• รูปที่ 2 - การพิสูจน์ตัวตนแบบไร้สัญชาติโดยไคลเอนต์บุคคลที่สาม

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

ประการแรก REST ไม่ใช่ศาสนาและไม่ควรเข้าใกล้เช่นนี้ ในขณะที่มีข้อได้เปรียบในการบริการ RESTful คุณควรปฏิบัติตามหลักการของ REST เท่าที่เหมาะสมสำหรับแอปพลิเคชันของคุณ

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

บริการเว็บของ Google เป็นตัวอย่างที่ยอดเยี่ยมของระบบ RESTful พวกเขาต้องการส่วนหัวการรับรองความถูกต้องพร้อมคีย์การตรวจสอบสิทธิ์ของผู้ใช้ที่จะส่งผ่านตามคำขอทุกครั้ง สิ่งนี้จะละเมิดหลักการ REST เล็กน้อยเนื่องจากเซิร์ฟเวอร์กำลังติดตามสถานะของคีย์การตรวจสอบสิทธิ์ ต้องรักษาสถานะของคีย์นี้และมีวันที่ / เวลาหมดอายุหลังจากนั้นจะไม่สามารถเข้าถึงได้อีกต่อไป อย่างไรก็ตามอย่างที่ฉันพูดถึงที่ด้านบนของโพสต์ของฉันต้องเสียสละเพื่อให้ใบสมัครทำงานได้จริง ดังกล่าวกล่าวว่าโทเค็นการรับรองความถูกต้องจะต้องเก็บไว้ในลักษณะที่ช่วยให้ลูกค้าที่เป็นไปได้ทั้งหมดเพื่อให้การเข้าถึงในช่วงเวลาที่ถูกต้องของพวกเขา หากเซิร์ฟเวอร์หนึ่งกำลังจัดการสถานะของคีย์การตรวจสอบสิทธิ์จนถึงจุดที่เซิร์ฟเวอร์โหลดบาลานซ์อื่นไม่สามารถตอบสนองคำขอตามคีย์นั้นได้ คุณเริ่มที่จะละเมิดหลักการของ REST จริงๆ บริการของ Google ช่วยให้มั่นใจได้ว่าคุณสามารถใช้โทเค็นการตรวจสอบสิทธิ์ที่คุณใช้บนโทรศัพท์ของคุณกับเซิร์ฟเวอร์ load load A และ hit load server B จากเดสก์ท็อปของคุณและยังสามารถเข้าถึงระบบและถูกนำไปยังทรัพยากรเดียวกันได้ คำขอเหมือนกัน

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

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

คุกกี้ไม่ได้มีไว้สำหรับการตรวจสอบ ทำไมต้องคิดค้นล้อใหม่ HTTP มีกลไกการพิสูจน์ตัวตนที่ออกแบบมาอย่างดี หากเราใช้คุกกี้เราจะใช้ HTTP เป็นโปรโตคอลการขนส่งเท่านั้นดังนั้นเราจำเป็นต้องสร้างระบบการส่งสัญญาณของเราเองเพื่อบอกผู้ใช้ว่าพวกเขาให้การรับรองความถูกต้องผิด (การใช้ HTTP 401 จะไม่ถูกต้องเพราะเราอาจจะไม่ จัดหาWww-Authenticateให้กับลูกค้าตามที่ HTTP ต้องการรายละเอียด :)) ควรสังเกตว่าSet-Cookieเป็นเพียงคำแนะนำสำหรับลูกค้า เนื้อหาอาจเป็นหรือไม่ได้รับการบันทึก (ตัวอย่างเช่นหากคุกกี้ถูกปิดใช้งาน) ในขณะที่Authorizationส่วนหัวจะถูกส่งโดยอัตโนมัติในทุกคำขอ

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

• คุณลองGET /aโดยไม่มีคุกกี้
• คุณได้รับคำขออนุญาตอย่างใด
• คุณไปและอนุญาตเหมือนอย่างใด POST /auth
• คุณได้รับ Set-Cookie
• คุณลองGET /a กับคุกกี้ แต่GET /aในกรณีนี้มีพฤติกรรมที่ไม่เหมาะสม

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

ที่จริงแล้ว RESTfulness ใช้เฉพาะกับทรัพยากรตามที่ระบุโดย Universal Resource Identifier ดังนั้นแม้แต่การพูดคุยเกี่ยวกับสิ่งต่าง ๆ เช่นส่วนหัวคุกกี้ ฯลฯ ที่เกี่ยวกับ REST นั้นไม่เหมาะสมจริงๆ REST สามารถทำงานกับโปรโตคอลใด ๆ แม้ว่ามันจะเกิดขึ้นกับ HTTP เป็นประจำ

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

ในกรณีของ POST หรือ PUT คุณสามารถส่ง URI / น้ำหนักบรรทุกที่กำหนดและไม่ว่าคุณจะส่งข้อความกี่ครั้งก็ตามข้อความนั้นจะอัปเดตข้อมูลเดิมเสมอดังนั้น GETs ต่อมาจะส่งคืนผลลัพธ์ที่สอดคล้องกันหรือไม่

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

ในการโพสต์บล็อกต่อไปนี้ Roy Fielding ได้สรุปความคิด REST ทั้งหมด:

http://groups.yahoo.com/neo/groups/rest-discuss/conversations/topics/5841

"ระบบ RESTful จะดำเนินต่อไปจากสถานะคงที่หนึ่งไปยังอีกสถานะหนึ่งและแต่ละสถานะคงที่นั้นอาจเป็นสถานะเริ่มต้นและสถานะปลายทางที่มีศักยภาพนั่นคือระบบ RESTful เป็นส่วนประกอบที่ไม่ทราบจำนวน กฎเช่นว่าพวกเขาจะอยู่ที่ REST หรือเปลี่ยนจากสถานะ RESTful หนึ่งไปยังสถานะ RESTful หนึ่งอีกครั้งแต่ละรัฐสามารถเข้าใจได้อย่างสมบูรณ์โดยการเป็นตัวแทนที่มีอยู่และชุดของช่วงการเปลี่ยนภาพที่มีให้ ชุดของการกระทำที่เข้าใจได้ระบบอาจเป็นแผนภาพสถานะที่ซับซ้อน แต่ตัวแทนผู้ใช้แต่ละรายสามารถเห็นสถานะหนึ่งครั้งเท่านั้น (สถานะคงที่ในปัจจุบัน) และทำให้แต่ละรัฐนั้นง่ายและสามารถวิเคราะห์ได้อย่างอิสระ ผู้ใช้ OTOH สามารถสร้างการเปลี่ยนแปลงของตนเองได้ตลอดเวลา (เช่นป้อน URL เลือกบุ๊คมาร์คเปิดโปรแกรมแก้ไข ฯลฯ ) "

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

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

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

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

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

ดังนั้นจึงไม่สามารถแก้ไขปัญหาได้โดยใช้การตรวจสอบสิทธิ์การเข้าถึงพื้นฐาน

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

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

สำหรับฉันมีหลายวิธีในการดูแลเซสชันผ่าน HTTP หนึ่งสามารถใช้คุกกี้กับ sessionId หรือส่วนหัวที่มี sessionId

หากใครมีความคิดอื่นฉันยินดีที่จะได้ยินมัน

ฉันคิดว่าโทเค็นต้องรวมข้อมูลที่จำเป็นทั้งหมดที่เข้ารหัสไว้ภายในซึ่งทำให้การตรวจสอบความถูกต้องโดยการตรวจสอบโทเค็นและถอดรหัสข้อมูล https://www.oauth.com/oauth2-servers/access-tokens/self-encoded-access-tokens/

1. การประชุมไม่สงบ
2. คุณหมายถึงบริการ REST สำหรับการใช้งานแบบ http เท่านั้นหรือว่าฉันผิดพลาด? เซสชันที่ใช้คุกกี้ต้องใช้สำหรับบริการ http-based ของตัวเอง (!) เท่านั้น! (อาจเป็นปัญหาในการทำงานกับคุกกี้เช่นจากมือถือ / คอนโซล / เดสก์ท็อป / ฯลฯ )
3. หากคุณให้บริการ RESTful สำหรับนักพัฒนาบุคคลที่สามอย่าใช้เซสชันที่อิงกับคุกกี้ใช้โทเค็นแทนเพื่อหลีกเลี่ยงปัญหาด้านความปลอดภัย