WebSocket nyitáskor HTTP fejléc küldése

A WebSocket kliens oldali része (leginkább a JavaScript miatt) kicsit homályos és ismeretlen számomra, gyorsan összedobtam egy kis példát tutorial alapján, működik is, megy SSL mögött, tudok rajta request paramétereket és üzeneteket is küldeni-fogadni mind a kliens, mind a szerver oldalon.

Viszont.

Szükségem lenne arra, hogy az alábbihoz hasonló módon egy plusz fejlécet (Authorization) küldjek el a kliens oldalról a szerver felé, hogy a socket authentikált legyen.

Alább egy kimásolt részlet, amelyet szeretnék:


GET /backend/ws/test HTTP/1.1
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
Authorization: Bearer eyJhbG...ZsTKs

HTTP/1.1 101 Switching Protocols
Connection: Upgrade
X-Powered-By: Undertow 1
Sec-WebSocket-Location: ws://null/backend/ws/test
Server: Wildfly 8
Upgrade: WebSocket
Content-Length: 0
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Date: Sat, 26 Jul 2014 09:29:36 GMT

Ezt nagyon szépen el tudom végezni egy telnet parancs segítségével, de nem találtam megoldást, hogy a böngészőben pure JavaScript használatával el tudjam küldeni a kapcsolat kiépítésekor ezt az egy nyamvadt fejlécet... :)

Nagyon elnéztem valamit és esetleg be tudom állítani globálisan, hogy küldje ezt a fejlécet, vagy tudtok esetleg valami (esetleg jQuery-re épülő) keretrendszert, amelyik tud ilyet?

Hozzászólások

A StackOverflow (http://stackoverflow.com/questions/4361173/http-headers-in-websockets-c…) szerint nem: http://stackoverflow.com/questions/4361173/http-headers-in-websockets-c…
Az első tippem nekem is az lett volna, amit a legalsó hozzászóló ír (token a request uriban vagy http basic auth).

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Igen, ezeket már olvastam... a szabvány elvileg lehetővé teszi, hogy legyen megszokott HTTP fejléc a WebSocket kiépítésekor és ezt a szerver figyelembe is veheti (ahogy látszik a WildFly-ban lévő Undertow ezt nagyon szépen kezeli is...

...csak valamiért úgy gondolták a böngészőben lévő WebSocket esetén ez nem kell... majd mindenki szépen kifejleszti magának az authentikációt és authorizációt kliens és szerver oldalon egyaránt... a baj az, hogy ezzel elvesztem a szerver oldalon azt, hogy a hívó context a teljes hívási lánc össze pontján tudja, hogy ki a kliens és milyen jogai vannak, nem kell nekem ezzel törődnöm, ha egy metódust védek azzal, hogy @RolesAllowed("admin"), akkor biztos lehetek benne, hogy ezt csak az a felhasználó tudja használni, akinek van "admin" szerepköre. Nem kell továbbadnom minden hívásnál, hogy ki volt a felhasználó és nem kell saját megoldásokat szögelnem, hogy lekérdezzem a jogait.

Egyelőre most csináltam workaround-ot, hogy a kliens átadja a request paraméterben az azonosításhoz szükséges adatokat, a szerver oldalon pedig módosítottam kicsit a WildFly-on, hogy ha van ilyen nevű paraméter, akkor azt vegye úgy, mintha fejlécben jött volna és most van egy szépen authentikált és authorizált WebSocket-em. :)
--
http://wiki.javaforum.hu/display/~auth.gabor/Home