Hi Tim,
On 2018-10-09 10:40 AM, Tim Düsterhus wrote:
Bob,
Am 05.10.2018 um 22:10 schrieb Computerisms Corporation:
Okay, this is something I hadn't looked at. Not 100% sure I am
interpreting correctly, but assuming I am, then the browser is reporting
that the connection is successfully upgrading to websockets both with
and without the Lua script enabled. As far as I can tell, the only
thing that changes is the cookies and keys. There is a significant
difference in the "waiting" response, though; ~350ms with the lua
script, but less than 5ms without it.
Use your browser's dev tools (F12 for Firefox, Chrome). Search for the
websocket request. It's just called '/websocket' for Etherpad. It should
return a 101 Switching Protocols. In Google Chrome you can even look at
the WebSocket Frames.
okay, that is what I was looking at, and yes, it does show the websocket
upgrade request, see below. it looks like the websockets upgrade is
/socket.io followed by some arguments denoted with a /?.
Can't paste, but it starts with a call to this file with code 200;
getting en-gb.json with code 304;
another call to /socket.io with code 200;
then the code 101 with an upgrade;
10 seconds later it shows a POST to the /socket.io with code 200.
b) Send credentials for basic authentication for Websockets.
hm, so I don't seem to be able to connect to etherpad directly using a
ws:// schematic in chrome or firefox, and I think that is what you mean.
not sure if that is just me, though, will work some more on that and
see if I can figure out if I am doing something wrong there...
No, use the dev tools and look at the request headers, whether there is
an Authorization header. Of course oauth_proxy needs to be enabled.
I think by oauth_proxy you mean the auth method I am using with the lua
script, in my case authnz_external from apache. if you literally mean
oauth_proxy, maybe this is the link I am missing. I have not configured
oauth_proxy any where, as I am/(was?) not planning to use it.
But by the request headers, I understand what you mean now. I am using
firefox primarily, but appears I get the same basic thing in chrome.
Firefox and Chrome both report 101 switching protocols, the websocket
upgrade header, and the authorization header:
Response headers (175 B)
Connection Upgrade
Sec-WebSocket-Accept gU996yXfDiutgquFxiRxGuffglc=
Sec-WebSocket-Extensions permessage-deflate
Upgrade websocket
Request headers (936 B)
Accept text/html,application/xhtml+xm…plication/xml;q=0.9,*/*;q=0.8
Accept-Encoding gzip, deflate, br
Accept-Language en-CA,en-US;q=0.7,en;q=0.3
Authorization Basic Ym9iQGNvbXB1dGVyaXNtcy5j…HMHJnZTB1cyhXZWUpRWdnbGl0cw==
Cache-Control no-cache
Connection keep-alive, Upgrade
Cookie _ga=GA1.2.1611432529.153149834…fFXUaWksCAAAJ; language=en-gb
Host pad.computerisms.ca
Origin https://pad.computerisms.ca
Pragma no-cache
Sec-WebSocket-Extensions permessage-deflate
Sec-WebSocket-Key DhxDcq4PkH+/TF2kaSW8JQ==
Sec-WebSocket-Version 13
Upgrade websocket
User-Agent Mozilla/5.0 (X11; Ubuntu; Linu…) Gecko/20100101 Firefox/62.0
I attached a screenshot of Chrome's dev tools.
Thanks, that confirms I am using the correct thing.
If you send me credentials in private I can take a look myself, if you want.
will follow up off list...
Best regards
Tim Düsterhus
