ส่วนหัว HTTP ใน API ไคลเอนต์ Websockets


204

ดูเหมือนว่าจะง่ายต่อการเพิ่มส่วนหัว HTTP ที่กำหนดเองไปยังไคลเอนต์ websocket ของคุณด้วยไคลเอนต์ส่วนหัว HTTP ใด ๆ ที่สนับสนุนสิ่งนี้ แต่ฉันไม่สามารถหาวิธีที่จะทำกับ JSON API

แต่ก็ดูเหมือนว่าควรจะมีการสนับสนุนส่วนหัวเหล่านี้ในสเปค

ทุกคนมีเงื่อนงำเกี่ยวกับวิธีการบรรลุหรือไม่

var ws = new WebSocket("ws://example.com/service");

โดยเฉพาะฉันต้องสามารถส่งส่วนหัว HTTP Authorization


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

คำแนะนำโดย @Motes ดูเหมือนจะเหมาะสมที่สุด มันง่ายมากที่จะทำการขออนุมัติจาก onOpen ซึ่งอนุญาตให้คุณยอมรับ / ปฏิเสธซ็อกเก็ตตามการตอบสนองการอนุญาต ตอนแรกฉันพยายามส่งโทเค็นรับรองความถูกต้องในส่วนหัว Sec-WebSocket-Protocol แต่รู้สึกเหมือนแฮ็ค
BatteryAcid

@Motes สวัสดีคุณช่วยอธิบายส่วน "บล็อกและรอบนเซิร์ฟเวอร์" ได้หรือไม่ คุณหมายถึงบางสิ่งที่ไม่ต้องการประมวลผลข้อความใด ๆ จนกว่าจะมีข้อความ "รับรองความถูกต้อง" หรือไม่
Himal

@ ขั้นสูงสุดใช่การออกแบบเซิร์ฟเวอร์จะต้องไม่ส่งข้อมูลหรือยอมรับข้อมูลอื่นใดนอกเหนือจากการให้สิทธิ์ในช่วงเริ่มต้นของการเชื่อมต่อ
Motes

@Motes ขอบคุณสำหรับการตอบกลับ ฉันสับสนเล็กน้อยโดยส่วนการปิดกั้นเนื่องจากความเข้าใจของฉันคุณไม่สามารถบล็อกconnectคำขอเริ่มต้นได้ ฉันใช้ช่อง Django ที่ด้านหลังและฉันได้ออกแบบให้ยอมรับการเชื่อมต่อกับconnectเหตุการณ์ จากนั้นจะตั้งค่าสถานะ "is_auth" ในreceiveเหตุการณ์ (หากเห็นข้อความรับรองความถูกต้องที่ถูกต้อง) หากไม่ได้ตั้งค่าสถานะ is_auth และไม่ใช่ข้อความรับรองความถูกต้องก็จะปิดการเชื่อมต่อ
Himal

คำตอบ:


214

อัปเดต 2x

คำตอบสั้น ๆ : ไม่สามารถระบุได้เฉพาะเส้นทางและเขตข้อมูลโปรโตคอล

คำตอบอีกต่อไป:

ไม่มีวิธีใน JavaScript WebSockets APIสำหรับระบุส่วนหัวเพิ่มเติมสำหรับไคลเอนต์ / เบราว์เซอร์ที่จะส่ง เส้นทาง HTTP ("GET / xyz") และส่วนหัวของโปรโตคอล ("Sec-WebSocket-Protocol") สามารถระบุได้ในตัวสร้าง WebSocket

ส่วนหัว Sec-WebSocket-Protocol (ซึ่งบางครั้งมีการขยายเพื่อใช้ในการรับรองความถูกต้องเฉพาะของ websocket) ถูกสร้างขึ้นจากอาร์กิวเมนต์ตัวเลือกที่สองไปยังตัวสร้าง WebSocket:

var ws = new WebSocket("ws://example.com/path", "protocol");
var ws = new WebSocket("ws://example.com/path", ["protocol1", "protocol2"]);

ผลลัพธ์ข้างต้นในส่วนหัวต่อไปนี้:

Sec-WebSocket-Protocol: protocol

และ

Sec-WebSocket-Protocol: protocol1, protocol2

รูปแบบทั่วไปสำหรับการบรรลุการรับรองความถูกต้อง / การอนุญาต WebSocket คือการใช้ระบบตั๋วที่หน้าโฮสต์ไคลเอ็นต์ WebSocket ร้องขอตั๋วจากเซิร์ฟเวอร์จากนั้นส่งตั๋วนี้ระหว่างการตั้งค่าการเชื่อมต่อ WebSocket ทั้งในสตริง URL / แบบสอบถามในฟิลด์โปรโตคอล หรือจำเป็นต้องเป็นข้อความแรกหลังจากการเชื่อมต่อถูกสร้างขึ้น เซิร์ฟเวอร์อนุญาตให้ทำการเชื่อมต่อต่อไปได้หากตั๋วถูกต้อง (มีอยู่, ไม่ได้ใช้งาน, มีการเข้ารหัส IP ไคลเอ็นต์ในการจับคู่ตั๋ว, ประทับเวลาในตั๋วเป็นล่าสุด ฯลฯ ) นี่คือบทสรุปของข้อมูลความปลอดภัย WebSocket: https://devcenter.heroku.com/articles/websocket-security

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

ข้อมูลรับรองความถูกต้องพื้นฐาน (คัดค้าน) :

ส่วนหัวการให้สิทธิ์ถูกสร้างขึ้นจากฟิลด์ชื่อผู้ใช้และรหัสผ่าน (หรือเพียงแค่ชื่อผู้ใช้) ของ WebSocket URI:

var ws = new WebSocket("ws://username:password@example.com")

ผลลัพธ์ข้างต้นในส่วนหัวต่อไปนี้ด้วยสตริง "ชื่อผู้ใช้: รหัสผ่าน" base64 ที่เข้ารหัส:

Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

ฉันได้ทดสอบการรับรองความถูกต้องเบื้องต้นใน Chrome 55 และ Firefox 50 แล้วและตรวจสอบว่าข้อมูลการรับรองความถูกต้องเบื้องต้นนั้นมีการเจรจากับเซิร์ฟเวอร์ (ซึ่งอาจไม่ทำงานใน Safari)

ขอบคุณ Dmitry Frank สำหรับคำตอบการตรวจสอบขั้นพื้นฐาน


39
ฉันเจอปัญหาเดียวกันแล้ว น่าเสียดายที่มาตรฐานเหล่านี้มีการบูรณาการไม่ดี คุณคาดหวังว่าพวกเขาจะดู XHR API เพื่อค้นหาข้อกำหนด (เนื่องจาก WebSockets และ XHR เกี่ยวข้องกับ) สำหรับ WebSockets API แต่ดูเหมือนว่าพวกเขากำลังพัฒนา API บนเกาะด้วยตัวเองเท่านั้น
eleotlecram

4
@eleotlecram เข้าร่วมคณะทำงานของ HyBi และเสนอมัน กลุ่มเปิดให้สาธารณชนและมีการทำงานอย่างต่อเนื่องสำหรับโปรโตคอลรุ่นต่อไป
Kanaka

5
@ Charlie: หากคุณควบคุมเซิร์ฟเวอร์อย่างเต็มที่นั่นเป็นทางเลือกหนึ่ง วิธีการทั่วไปในการสร้างตั๋ว / โทเค็นจากเซิร์ฟเวอร์ HTTP ปกติของคุณแล้วให้ลูกค้าส่งตั๋ว / โทเค็น (ไม่ว่าจะเป็นสตริงการสืบค้นในเส้นทาง websocket หรือเป็นข้อความ websocket แรก) จากนั้นเซิร์ฟเวอร์ websocket จะตรวจสอบว่าตั๋ว / โทเค็นนั้นถูกต้อง (ยังไม่หมดอายุไม่ได้ใช้งานมาจาก IP เดียวกันกับที่สร้างขึ้น ฯลฯ ) นอกจากนี้ฉันเชื่อว่าไคลเอนต์เว็บซ็อกเก็ตส่วนใหญ่สนับสนุนการรับรองความถูกต้องพื้นฐาน (อาจไม่เพียงพอสำหรับคุณ) ข้อมูลเพิ่มเติม: devcenter.heroku.com/articles/websocket-security
kanaka

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

3
น่าเสียดายที่นี่ดูเหมือนจะไม่ทำงานใน Edge ขอบคุณ MS: /
sibbl

42

โซลูชันสำรองเพิ่มเติม แต่เบราว์เซอร์สมัยใหม่ทั้งหมดส่งคุกกี้โดเมนพร้อมกับการเชื่อมต่อดังนั้นการใช้:

var authToken = 'R3YKZFKBVi';

document.cookie = 'X-Authorization=' + authToken + '; path=/';

var ws = new WebSocket(
    'wss://localhost:9000/wss/'
);

จบลงด้วยส่วนหัวการเชื่อมต่อคำขอ:

Cookie: X-Authorization=R3YKZFKBVi

1
ดูเหมือนจะเป็นวิธีที่ดีที่สุดในการส่งโทเค็นการเข้าถึงผ่านการเชื่อมต่อ ในขณะนี้
cammil

2
เกิดอะไรขึ้นถ้าเซิร์ฟเวอร์ WS URI แตกต่างจากไคลเอ็นต์ URI
ภาษาเดนมาร์ก

1
@Danish ถ้าอย่างนั้นก็ใช้งานไม่ได้เพราะคุณไม่สามารถตั้งค่าคุกกี้สำหรับฝั่งไคลเอนต์อื่น ๆ ได้
Tofandel

1
แต่คุณสามารถตั้งค่าบริการ HTTP ที่ตั้งค่าคุกกี้เซสชันในเส้นทางที่เกี่ยวข้องและโทรไปที่ก่อนเริ่ม websocket ของคุณ โทรพูดhttps://example.com/loginและให้การตอบรับตั้งค่าคุกกี้/wssจากนั้นnew WebSocket("wss://example.com/wss")จะเริ่มคำขอจับมือกับคุกกี้ที่เกี่ยวข้อง โปรดทราบว่า devtools อาจไม่แสดงคุกกี้ แต่ควรส่ง
Coderer

34

ปัญหาส่วนหัว HTTP Authorization สามารถแก้ไขได้ดังต่อไปนี้:

var ws = new WebSocket("ws://username:password@example.com/service");

จากนั้นส่วนหัว HTTP การอนุญาตพื้นฐานที่เหมาะสมจะถูกตั้งค่าด้วยการให้ usernamepasswordและ หากคุณต้องการการอนุญาตขั้นพื้นฐานคุณก็พร้อมแล้ว


ฉันต้องการใช้ Bearerอย่างไรก็ตามและฉันหันไปใช้เคล็ดลับต่อไปนี้: ฉันเชื่อมต่อกับเซิร์ฟเวอร์ดังนี้:

var ws = new WebSocket("ws://my_token@example.com/service");

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


12
ฉันกำลังพยายามแก้ปัญหาที่คุณแนะนำ แต่ฉันไม่เห็นส่วนหัวการให้สิทธิ์ถูกเพิ่มลงในคำขอของฉัน ฉันได้ลองใช้เบราว์เซอร์ที่แตกต่างกันเช่น Chrome V56, Firefox V51.0 ฉันใช้เซิร์ฟเวอร์ของฉันบนโฮสต์ของฉัน ดังนั้น websocket url คือ "ws: // myusername: mypassword @ localhost: 8080 / mywebsocket" ความคิดใด ๆ ที่อาจจะผิด ขอบคุณ
LearnToLive

4
การโอนโทเค็นผ่าน URL ปลอดภัยหรือไม่
Mergasov

9
ฉันเห็นด้วยกับ @LearnToLive - ฉันใช้สิ่งนี้กับ wss (เช่นwss://user:password@myhost.com/ws) และไม่มีAuthorizationส่วนหัวที่ฝั่งเซิร์ฟเวอร์ (โดยใช้ Chrome รุ่น 60)
user9645

6
ฉันมีปัญหาเช่นเดียวกับ @LearnToLive และ @ user9645; ทั้ง chrome และ firefox ไม่ได้เพิ่มหัวข้อการให้สิทธิ์เมื่อ URI อยู่ในwss://user:pass@hostรูปแบบ เบราว์เซอร์นี้ไม่รองรับหรือมีบางอย่างผิดปกติกับการจับมือกันหรือไม่?
David Kaczynski

4
การใช้ URL เหล่านี้http://username:password@example.comจะถูกคิดค่าเสื่อมราคา developer.mozilla.org/en-US/docs/Web/HTTP/Authentication อาจเป็นเหตุผลว่าทำไมมันไม่ทำงานกับ websockets ด้วยเช่นกัน!
Dachstein

19

คุณไม่สามารถเพิ่มส่วนหัว แต่ถ้าคุณเพียงแค่ต้องส่งค่าไปยังเซิร์ฟเวอร์ในขณะที่การเชื่อมต่อคุณสามารถระบุส่วนสตริงแบบสอบถามใน URL:

var ws = new WebSocket("ws://example.com/service?key1=value1&key2=value2");

URL นั้นถูกต้อง แต่แน่นอนว่าคุณจะต้องแก้ไขรหัสเซิร์ฟเวอร์ของคุณเพื่อแยกวิเคราะห์


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

5
@Nir กับ WSS การสอบถามน่าจะปลอดภัย
Sebastien Lorber

8
ws เป็นข้อความธรรมดา การใช้โปรโตคอล ws สามารถสกัดกั้นสิ่งใดก็ได้
Gabriele Carioli

1
@SebastienLorber มันไม่ปลอดภัยที่จะใช้สตริงการสืบค้นมันไม่ได้ถูกเข้ารหัสเหมือนกับ HTTPS แต่เนื่องจากใช้โปรโตคอล "ws: // ... " มันไม่สำคัญเลย
Lu4

5
@ Lu4 สตริงแบบสอบถามมีการเข้ารหัส แต่มีโฮสต์ของเหตุผลอื่น ๆ ที่จะไม่เพิ่มข้อมูลที่สำคัญเป็น URL แบบสอบถามพารามิเตอร์stackoverflow.com/questions/499591/are-https-urls-encrypted/... & blog.httpwatch.com/2009 /

17

คุณไม่สามารถส่งส่วนหัวที่กำหนดเองเมื่อคุณต้องการสร้างการเชื่อมต่อ WebSockets โดยใช้ JavaScript WebSockets API คุณสามารถใช้Subprotocolsส่วนหัวโดยใช้ตัวสร้างคลาส WebSocket ที่สอง:

var ws = new WebSocket("ws://example.com/service", "soap");

จากนั้นคุณสามารถรับส่วนหัว Subprotocols โดยใช้Sec-WebSocket-Protocolคีย์บนเซิร์ฟเวอร์

นอกจากนี้ยังมีข้อ จำกัด ค่าส่วนหัว Subprotocols ของคุณต้องไม่มีเครื่องหมายจุลภาค ( ,)!


1
Jwt มีเครื่องหมายจุลภาคหรือไม่
CESCO

1
ฉันไม่เชื่ออย่างนั้น JWT ประกอบด้วยเพย์โหลดที่เข้ารหัส base64 สามอันแต่ละอันคั่นด้วยจุด ฉันเชื่อว่ากฎนี้เป็นไปได้ของเครื่องหมายจุลภาค
BillyBBone

2
ฉันใช้งานสิ่งนี้และใช้งานได้ - รู้สึกแปลก ๆ ขอบคุณ
BatteryAcid

3
คุณแนะนำให้เราใช้Sec-WebSocket-Protocolส่วนหัวเป็นทางเลือกแทนAuthorizationส่วนหัวหรือไม่
rrw

14

ไม่สามารถส่งส่วนหัวการให้สิทธิ์ได้

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

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

สร้างแยกต่างหาก JwtAuthHandler เส้นทางเดียวกับที่คุณลงทะเบียน SockJS eventbusHandler บน ตรวจสอบให้แน่ใจว่าตัวจัดการรับรองความถูกต้องของคุณลงทะเบียนก่อนดังนั้นคุณสามารถตรวจสอบโทเค็นเว็บซ็อกเก็ตกับฐานข้อมูลของคุณ (JWT ควรเชื่อมโยงกับผู้ใช้ของคุณในแบ็กเอนด์)


นี่เป็นทางออกเดียวที่ปลอดภัยที่ฉันสามารถใช้กับ API เกตเวย์เว็บได้ Slack ทำสิ่งที่คล้ายกับ RTM API ของพวกเขาและพวกเขามีเวลา 30 วินาที
andrhamm

2

แฮ็คทั้งหมดแบบนี้ต้องขอบคุณคำตอบของ kanaka

ลูกค้า:

var ws = new WebSocket(
    'ws://localhost:8080/connect/' + this.state.room.id, 
    store('token') || cookie('token') 
);

เซิร์ฟเวอร์ (ใช้ Koa2 ในตัวอย่างนี้ แต่ควรคล้ายกันทุกที่):

var url = ctx.websocket.upgradeReq.url; // can use to get url/query params
var authToken = ctx.websocket.upgradeReq.headers['sec-websocket-protocol'];
// Can then decode the auth token and do any session/user stuff...

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

0

กรณีของฉัน:

  • ฉันต้องการเชื่อมต่อกับเซิร์ฟเวอร์ WS ที่ใช้งานจริงwww.mycompany.com/api/ws...
  • ใช้ข้อมูลรับรองจริง (คุกกี้เซสชัน) ...
  • จากหน้าเว็บท้องถิ่น ( localhost:8000)

การตั้งค่าdocument.cookie = "sessionid=foobar;path=/"จะไม่ช่วยเมื่อโดเมนไม่ตรงกัน

ทางออก :

เพิ่มไป127.0.0.1 wsdev.company.com/etc/hosts

วิธีนี้เบราว์เซอร์ของคุณจะใช้คุกกี้จากmycompany.comเมื่อเชื่อมต่อกับขณะที่คุณกำลังเชื่อมต่อจากโดเมนย่อยที่ถูกต้องwww.mycompany.com/api/wswsdev.company.com


-1

ในสถานการณ์ของฉัน(Azure Time Series Insights wss: //)

ใช้ ReconnectingWebsocket wrapper และสามารถเพิ่มส่วนหัวด้วยโซลูชันง่ายๆ:

socket.onopen = function(e) {
    socket.send(payload);
};

โดยที่ payload ในกรณีนี้คือ:

{
  "headers": {
    "Authorization": "Bearer TOKEN",
    "x-ms-client-request-id": "CLIENT_ID"
}, 
"content": {
  "searchSpan": {
    "from": "UTCDATETIME",
    "to": "UTCDATETIME"
  },
"top": {
  "sort": [
    {
      "input": {"builtInProperty": "$ts"},
      "order": "Asc"
    }], 
"count": 1000
}}}

-3

ในทางเทคนิคคุณจะส่งส่วนหัวเหล่านี้ผ่านฟังก์ชั่นการเชื่อมต่อก่อนขั้นตอนการอัพเกรดโปรโตคอล สิ่งนี้ใช้ได้สำหรับฉันในnodejsโครงการ:

var WebSocketClient = require('websocket').client;
var ws = new WebSocketClient();
ws.connect(url, '', headers);

3
นี่สำหรับไคลเอ็นต์ websocket เป็น npm (สำหรับโหนด) npmjs.com/package/websocketโดยรวมนี่จะเป็นสิ่งที่ฉันกำลังมองหา แต่ในเบราว์เซอร์
arnuschky

1
มันถูกลดระดับลงเนื่องจากพารามิเตอร์ส่วนหัวนี้อยู่ในเลเยอร์โปรโตคอล WebSocket และคำถามเกี่ยวกับส่วนหัว HTTP
Toilal

"headersควรเป็น null หรือวัตถุที่ระบุส่วนหัวคำขอ HTTP เพิ่มเติมโดยพลการเพื่อส่งไปพร้อมกับคำขอ" จากWebSocketClient.md ; ดังนั้นที่headersนี่คือชั้น HTTP
momocow

นอกจากนี้ทุกคนที่ต้องการที่จะให้ส่วนหัวที่กำหนดเองควรจะเก็บไว้ในใจลายเซ็นการทำงานของconnectวิธีการอธิบายว่าconnect(requestUrl, requestedProtocols, [[[origin], headers], requestOptions])คือheadersควรจะให้พร้อมกับยกตัวอย่างเช่นrequestOptions ws.connect(url, '', headers, null)เฉพาะoriginสตริงที่สามารถละเว้นได้ในกรณีนี้
momocow

-3

คุณสามารถผ่านส่วนหัวเป็นคีย์ - ค่าในพารามิเตอร์ที่สาม (ตัวเลือก) ภายในวัตถุ ตัวอย่างที่มีโทเค็นการอนุญาต ปล่อยให้โปรโตคอล (พารามิเตอร์ที่สอง) เป็นโมฆะ

ws = ใหม่ WebSocket ('ws: // localhost', null, {ส่วนหัว: {การอนุญาต: token}})

แก้ไข: ดูเหมือนว่าวิธีนี้ใช้ได้กับไลบรารี nodejs เท่านั้นไม่ได้ใช้เบราว์เซอร์มาตรฐาน ออกไปเพราะบางคนอาจมีประโยชน์


หากว่าฉันมีความหวังในอีกสักครู่ ดูเหมือนจะไม่มีการใช้งานเกินกำลังโดยใช้พารามิเตอร์ที่ 3 ใน ctor WebSocket
Levitikon

มีแนวคิดจากรหัส wscat github.com/websockets/wscat/blob/master/bin/wscatบรรทัด 261 ซึ่งใช้แพ็คเกจ ws คิดว่านี่เป็นการใช้มาตรฐาน
Nodens
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.