Adam Barth wrote:
Generally speaking, browsers have been moving away from triggering
authentication dialogs for subresource loads because they are more
often used for phishing than for legitimate purposes. A WebSocket
connection is much like a subresource load.
Couldn't we only allow digest-based 401/407 authentication for
subresource loads so an attacker cannot simply obtain unencrypted
credentials?
The latest WebSocket protocol spec [1] says:
"This protocol doesn't prescribe any particular way that servers can
authenticate clients during the WebSocket handshake. The WebSocket
server can use any client authentication mechanism available to a
generic HTTP server, such as Cookies, HTTP Authentication, TLS
authentication."
Without HTTP Auth and the difficulty/performance issues of doing TLS
auth in pure JavaScript it seems we are left with a cookie-only
authentication option.
Disabling support for Basic HTTP Authentication but still ticking the
box for HTTP auth, with the added benefit that all such HTTP auth will
be encrypted, seems like a win-win here.
- Rich
[1]
http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-13#page-54
On Wed, Aug 10, 2011 at 9:36 PM, Brian Raymor
<[email protected]> wrote:
What is the rationale for also failing the websocket connection when a response
for authentication is received such as:
401 Unauthorized
407 Proxy Authentication Required
