ออกจากระบบ: GET หรือ POST

434

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

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

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

ทุกอย่างที่ฉันได้อ่านเพื่อให้ห่างไกลชี้ให้เห็นว่าการโพสต์ควรจะใช้สำหรับ "การกระทำการทำลายล้าง" ในขณะที่การกระทำที่ไม่เปลี่ยนสภาวะภายในของแอพลิเคชันเหมือนสอบถามและ such- ควรจะจัดการกับ GET จากนี้คำถามจริงที่นี่คือ:

การออกจากระบบของแอปพลิเคชันถือเป็นการกระทำที่เป็นการทำลายหรือไม่หรือเป็นการเปลี่ยนแปลงสถานะภายในของแอปพลิเคชัน

— Daniel Liuzzi
แหล่งที่มา

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

— HyperCas

2

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

— Daniel Liuzzi

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

— อเล็กซ์

3

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

— Daniel Liuzzi

1

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

— Rob Grant

475

POSTใช้

ในปี 2010 การใช้GETอาจเป็นคำตอบที่ยอมรับได้ แต่วันนี้ (ในปี 2013) เบราว์เซอร์จะดึงข้อมูลหน้าเว็บล่วงหน้าที่พวกเขา "คิด" คุณจะเข้าชมต่อไป

นี่คือหนึ่งในนักพัฒนา StackOverflow ที่พูดถึงปัญหานี้ใน twitter:

ฉันขอขอบคุณธนาคารของฉันสำหรับการออกจากระบบคำขอ GET และทีมงาน Chrome สำหรับการดึง URL ที่มีประโยชน์ล่วงหน้า - Nick Craver ( @Nick_Craver ) 29 มกราคม 2013

ข้อเท็จจริงที่สนุกสนาน: StackOverflow ใช้เพื่อจัดการการล็อกเอาต์ผ่าน GET แต่ไม่ใช่อีกต่อไป

— เดวิดเมอร์ด็อก
แหล่งที่มา

2

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

— Daniel Liuzzi

4

ในเบราว์เซอร์ของฉันการออกจากระบบของ Stackoverflow ดูเหมือน <li> <a href="https://stackoverflow.com/users/logout"> ออกจากระบบ </a> </li> ซึ่งเป็น GET ไม่ใช่ POST

— boatcoder

9

@ Mark0978 คลิกลิงก์

— David Murdoch

2

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

— boatcoder

7

@Red ตามมาตรฐาน HTTP / 1.1 นี่เป็นความผิดพลาดของเซิร์ฟเวอร์ไม่ใช่ของเบราว์เซอร์ GET คาดว่าจะไม่มีผลข้างเคียงทางฝั่งเซิร์ฟเวอร์ มาตรฐานยังพูดว่า "ผู้ใช้ไม่ได้ร้องขอผลข้างเคียงดังนั้นจึงไม่สามารถรับผิดชอบต่อพวกเขาได้"

— eyuelt

45

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

สิ่งที่คุณถามจริงๆคือเบราว์เซอร์ควรส่งข้อมูลการตรวจสอบสิทธิ์ไปยังทุกคำขอต่อไป

หากใบสมัครของคุณสร้างภาพลวงตาของการเข้าสู่ระบบคุณควรจะสามารถ "ออกจากระบบ" โดยใช้ javascript ไม่ต้องเดินทางไปกลับ

วิทยานิพนธ์ Fielding - ส่วน 5.1.3

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

— Darrel Miller
แหล่งที่มา

1

จริง ๆ แล้วฉันก็ไม่รู้เรื่องนี้ จากนั้นฉันเดาว่าแอปของฉันจะไม่สงบมากเลยเพราะฉันใช้ ASP.NET MVC กับ FormsAuthentication และขึ้นอยู่กับการใช้ ...

— Daniel Liuzzi

19

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

— Remus Rusanu

6

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

— Remus Rusanu

1

@Remus Ahhh เว็บเบราว์เซอร์ที่โด่งดังทำให้การเขียนแอพพลิเคชั่นบนเว็บเจ็บปวดมาก

— Darrel Miller

1

@DarrelMiller ใช่ แต่ไม่เพิกถอน JWT ที่ฝั่งเซิร์ฟเวอร์เป็นช่องโหว่ด้านความปลอดภัย แม้ว่าโทเค็นจะไม่ถูกเก็บไว้ในเซิร์ฟเวอร์พวกเขาควรจะอยู่ในบัญชีดำเมื่อผู้ใช้ออกจากระบบ / เปลี่ยนรหัสผ่าน / เปลี่ยนบทบาท / เลิก / ฯลฯ เพื่อป้องกันการละเมิด (อย่างน้อยก็จนกว่าพวกเขาจะหมดอายุ)

— java-addict301

38

วิธีหนึ่งที่GETอาจถูกทารุณกรรมได้ที่นี่คือบุคคล (คู่แข่งอาจ :) วางแท็กรูปภาพพร้อมกับที่src="<your logout link>"ใดก็ได้บนอินเทอร์เน็ตและหากผู้ใช้ไซต์ของคุณสะดุดที่หน้านั้นเขาจะถูกออกจากระบบโดยไม่รู้ตัว

— raveren
แหล่งที่มา

4

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

— Richard H

4

ว้าวฉันไม่เคยคิดเลย! ดังนั้นมีอีกเหตุผลที่ไม่ใช้ GET และอีกเหตุผลหนึ่งที่ฉันไม่เข้าใจว่าทำไมทุกคนทำ ตอนนี้ฉันถูก temped เพื่อรวมstackoverflow.com/users/logout "ภาพ" โพสต์ของฉันและดูว่าเกิดอะไรขึ้น :-D

— Daniel Liuzzi

24

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

— เรเวอเรน

12

SuperLogout.comทำเช่นนั้น (โหลด/logoutURL ในภาพที่ซ่อนอยู่) และใช้งานได้

— Dan Dascalescu

9

Re: SuperLogout ... ฉันไม่รู้ว่าทำไมฉันจึงคลิกมัน

— MI Wright

21

เพื่อให้ถูกต้อง GET / POST (หรือคำกริยาอื่น ๆ ) เป็นการกระทำในทรัพยากรบางอย่าง (ระบุโดย URL) - ดังนั้นโดยทั่วไปเกี่ยวกับสถานะของทรัพยากรและไม่เกี่ยวกับสถานะของแอปพลิเคชันเช่นนี้ ดังนั้นในวิญญาณที่แท้จริงคุณควรมี URL เช่น[host name]\[user name]\sessionนั้น 'DELETE' จะเป็นคำกริยาที่ถูกต้องสำหรับการออกจากระบบ

การใช้[host name]\bla bla\logoutเป็น URL ไม่ใช่วิธีที่สมบูรณ์แบบ (IMO) ดังนั้นทำไมการอภิปรายเกี่ยวกับการใช้ GET / POST อย่างถูกต้อง

แน่นอนฉันยังใช้ GET กับ URL การล็อกเอาต์ในแอปพลิเคชันของฉัน :-)

— VinayC
แหล่งที่มา

2

ในกรณีนั้นฉันจะยืนยันว่าการมีส่วน [ชื่อผู้ใช้] ใน URL ดูเหมือนไม่จำเป็นเนื่องจากผู้ใช้ออกจากระบบเสมอ (เช่นลบ) เซสชันของตนเอง ไม่ผู้ใช้รายอื่น ':-)

— Daniel Liuzzi

1

ไม่จริง - เรากำลังพูดว่าเซสชันนั้นเป็นทรัพยากรและเราต้องการลบทิ้ง ดังนั้นสำหรับที่อยู่เซสชันใด ๆ อย่างสม่ำเสมอคุณต้องมีชื่อผู้ใช้เป็นส่วนหนึ่งของ URL อาร์กิวเมนต์ของคุณดีพอ ๆ กับการบอกว่าการออก PUT แอ็คชั่นใน [คลังภาพ] \ pictures หมายความว่าคุณกำลังเพิ่มรูปภาพของคุณ (มีอยู่ที่ [แกลเลอรีภาพ] \ [ชื่อผู้ใช้] \ pictures แหล่งข้อมูลที่แตกต่างกันจะต้องได้รับการจัดการอย่างชัดเจนไม่สามารถบอกเป็นนัยได้ ไซต์อาจอนุญาตให้ผู้ใช้รายอื่นเพิ่มรูปภาพในแกลเลอรีของคุณ - เป็นส่วนหนึ่งของการควบคุมการเข้าถึงเช่นเดียวกับที่คุณมีผู้ใช้ขั้นสูงที่สามารถฆ่าเซสชันของใครก็ได้

— VinayC

1

การพูดเชิงปรัชญาคุณสามารถเรียกเซสชันและทรัพยากร 'ภาพถ่าย' แต่ในความเป็นจริงฉันจะไม่ปฏิบัติต่อพวกเขาเหมือนกัน เซสชันจะถูก จำกัด อยู่ภายในผู้ใช้ปัจจุบัน (ดังนั้นจึงเป็นชื่อเซสชัน) และอย่างน้อยใน ASP.NET ไม่มีวิธีการเข้าถึงเซสชันของผู้ใช้อื่น แม้แต่ผู้พัฒนาแอพพลิเคชั่นก็ไม่สามารถระบุเซสชันที่ใช้งานได้โดยตรงทั้งหมด คุณสามารถรีสตาร์ทแอปพลิเคชันเพื่อฆ่าเซสชันทั้งหมด (InProc) แต่ฉันจะไม่เรียกการควบคุมการเข้าถึงนั้น นอกจาก URL แล้วคำถามยังคงอยู่: GET หรือ POST

— Daniel Liuzzi

ทรัพยากรดังนั้นที่อยู่ (URL) จึงเป็นส่วนสำคัญของ REST ดังนั้นหากคุณเลือก URL ตามที่ฉันพูด DELETE จะกลายเป็นคำที่ถูกต้องไม่ใช่ GET หรือ POST นอกจากนี้แม้ว่าคุณจะ จำกัด ตัวเองกับ ASP.NET คุณสามารถมีผู้ให้บริการสถานะที่กำหนดเองของคุณที่สามารถให้วิธีการระบุผ่านเซสชันและฆ่าเซสชันอื่น ๆ หากจำเป็น สำหรับเซสชันนอกกรอบที่เล่นซอบางคนใน global.asax ควรให้ฟังก์ชั่นการใช้งาน มันเป็นคำถามจริงๆว่าฟังก์ชั่นดังกล่าวจะต้องใช้หรือไม่ สำหรับความต้องการไม่บ่อยนักผู้คนมักจะเริ่มเว็บไซต์ใหม่เพื่อดึงผู้คนออกจากเว็บไซต์

— VinayC

สิ่งนี้สมเหตุสมผลที่สุดสำหรับฉัน กำหนดเส้นทางเซสชันของเว็บและเรียกใช้ DELETE เป็นไปได้ว่า ../session หรือ ../session/current ขอบคุณ @VinayC

— Simon Hooper

16

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

— Joel Etherton
แหล่งที่มา

ที่น่าสนใจ; ฉันไม่เคยคิดแบบนี้ +1

— แปลกหน้า

สิ่งนี้อาจขึ้นอยู่กับแอปพลิเคชัน (พฤติกรรมบางอย่าง "ลบซ้อน" บางอย่าง) แต่คุณพูดถูก

— Andres Jaan Tack

@ JoelEtherton ขอบคุณ Joel ฉันกำลังอ่านคำตอบที่สงสัยว่าเมื่อไหร่ที่จะไปถึงจุดที่ถูกต้อง :)

— คิริลล์ฟิวค์

4

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

— Michael Cole

1

@MichaelCole: ฉันจะเห็นด้วยกับการเป็นตัวแทนของความยากลำบากระหว่าง POST และ GET ฉันไม่เห็นด้วยกับการใช้คำกริยา DELETE DELETE ใช้สำหรับจัดการทรัพยากรและเซสชันไม่ใช่ทรัพยากรในแง่นี้ ลองพิจารณาถ้าคุณสามารถลบมันได้คุณควรจะใส่มันเข้าไปด้วย

— Joel Etherton

16

สวัสดีในมุมมองของฉันเมื่อคุณเข้าสู่ระบบคุณตรวจสอบชื่อผู้ใช้ / รหัสผ่านและถ้าตรงกับที่คุณสร้างโทเค็นเข้าสู่ระบบ

CREAT token => วิธีPOST

เมื่อคุณออกจากระบบคุณทำให้โทเค็นรบกวนฉันวิธีที่มีเหตุผลที่สุดคือ DELETE

DELETE token => method DELETE

— miorey
แหล่งที่มา

4

มุมที่น่าสนใจ

— Drumbeg

1

ฉันใช้วิธีนั้นในแอปพลิเคชัน Spring Boot REST ของฉัน

— Please_Dont_Bully_Me_SO_Lords

1

ถูกต้องทางความหมาย ฉันเห็นด้วย ...

— DAG

1

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

หรืออาจจะใช้ลิงค์ในจาวาสคริปต์?

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

— Richard H
แหล่งที่มา

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

— Daniel Liuzzi

0

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

— ปล้น
แหล่งที่มา

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

— Daniel Liuzzi

สคริปต์การออกจากระบบจะสิ้นสุดเซสชันของผู้ใช้ (จริง ๆ แล้ว: เบราว์เซอร์) เรียกมัน ใน ASP.net เซสชันเป็นวัตถุฝั่งเซิร์ฟเวอร์ซึ่งสามารถละทิ้งได้ PHP มีระบบที่คล้ายกัน เนื่องจากเบราว์เซอร์นั้นเรียกใช้สคริปต์ที่สิ้นสุดเซสชันดังนั้นจึงรู้ว่าจะต้องหยุดใช้งานเมื่อใดจึงไม่จำเป็นต้องใช้ตัวแปร POST หรือ GET

— Rob

1

ใช่ฉันรับคุณแล้ว ฉันมีสคริปต์อยู่แล้วโดยเฉพาะ FormsAuthentication.SignOut () แต่คำถามของฉันเกี่ยวกับวิธีการเรียกใช้สคริปต์เช่นเดียวกับใน GET หรือ POST

— Daniel Liuzzi

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

— Rob

0

เมื่อเร็ว ๆ นี้ฉันกำลังทำงานในโครงการที่ฉันใช้ GET เพื่อออกจากระบบด้านล่างเป็นรหัสใน Nodejs Express และมันทำงานได้อย่างสมบูรณ์แบบ

เราเตอร์ของคุณ

const express = require("express");
router.get("/signout", signout);

your controller.js

exports.signout  = (req, res) => {
        res.clearCookie('t'); //clearing cookie, which is 
            //assign to the user during sign in.          
            res.json({message : 'Signout success'});   
        };

— xSachinx
แหล่งที่มา

-2

ฉันไม่เห็นว่าการออกจากระบบ (การยกระดับสิทธิ์ของผู้ใช้) เป็นการกระทำที่เป็นการทำลาย นั่นเป็นเพราะการกระทำ "ออกจากระบบ" ควรจะใช้ได้เฉพาะกับผู้ใช้ที่เข้าสู่ระบบแล้วมันจะล้าสมัย

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

— jpluijmers
แหล่งที่มา

2

wgetในโหมดสไปเดอร์ที่มีคุกกี้เซสชันที่ถูกต้องบนวิกิส่วนตัวเป็นสิ่งที่ฉันต้องทำครั้งเดียว แน่นอนหนึ่งของ URL /logoutที่รวบรวมข้อมูลครั้งแรกคือ

— Helgi

5

ลองไปที่SuperLogout.comเพื่อดูว่า GET ทำลายคำขอไปยัง/logoutหน้าเว็บได้อย่างไร ตัวอย่างเช่นคุณจะต้องลงชื่อเข้าใช้ Gmail อีกครั้งลงชื่อเข้าใช้การแชทอีกครั้งค้นหาสถานที่ของคุณในการสนทนาแฮงเอาท์ที่คุณเลื่อน ฯลฯ - และนี่เป็นเพียงสำหรับ Google.com เท่านั้น

— Dan Dascalescu