New issue
Advanced search Search tips
Starred by 137 users

Issue metadata

Status: Fixed
Owner:
Closed: Oct 2014
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug

Blocked on:
issue 116624
issue 226931



Sign in to add a comment

WebSocket upgrade handshake does not handle HTTP status 401

Reported by rebel7...@gmail.com, Apr 17 2012

Issue description

Chrome Version       : 18.0.1025.162
OS Version: 6.1 (Windows 7)
URLs (if applicable) :
Other browsers tested:
  Firefox 11.0 OK
issue:
This is a request to reconsider  Issue 46906 .

I support a Home Automation system web server application that uses websockets. One of its security methods is username/password basic authorization, using Authorization: Basic and a specific cookie.

When upgrading to a websocket from a connection that has been set up with Basic Authorization, Chrome does not include the Authorization header. This causes the server to request usrname/password (i.e. it issues a 401 response) which the client ignores, causing the websocket connection to close.

Previously  Issue 46906  was resolved as "WontFix" because the websocket spec does not specifically address Basic Authorization. However, I believe that this is an oversight. In fact, Chrome DOES include the specific cookie sent to it by the server in the websocket upgrade request, although it isn't explicitly stated as required.


What steps will reproduce the problem?
1. Set up a normal HTTP connection with the home automation server using username/password authorization.
2. JavaScript in the fetched page sets up a websocket connection
3. Server responds with 401, and browser closes websocket with 1006 code.

What is the expected result?
After a successful HTTP Basic Auth connection, Chrome initiated a websocket request.
Chrome sends:
GET / HTTP/1.1
Upgrade: websocket
Connection: Upgrade
Host: localhost:8080
Origin: http://localhost:8080
Sec-WebSocket-Key: xxxxxxxxxxxxxxxxxxx
Sec-WebSocket-Version: 13
Cookie: HomeVisionAuthorization=xxxxxxxxxxxxxxxxxx
Authorization: Basic xxxxxxxxxxxxxxxx

Server responds with:
HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Accept: xxxxxxxxxxxxxxxxxx



What happens instead?
Chrome sends:
GET / HTTP/1.1
Upgrade: websocket
Connection: Upgrade
Host: localhost:8080
Origin: http://localhost:8080
Sec-WebSocket-Key: xxxxxxxxxxxxxxxx
Sec-WebSocket-Version: 13
Cookie: HomeVisionAuthorization=xxxxxxxxxxxxx

Since the Authorization header is missing, the server responds with 401, websocket connection closes with 1006 code.


Please provide any additional information below. Attach a screenshot if
possible.

UserAgentString: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.162 Safari/535.19


 

Comment 1 by mmenke@chromium.org, Apr 18 2012

Labels: -Area-Undefined Area-WebKit WebKit-WebSockets

Comment 2 by rebel7...@gmail.com, Apr 21 2012

Chrome should also allow websocket set-up to include Authorization without a preceding HTTP Auth. For example, a browser may use a local file to generate the websocket request to the remote server. In this case, the websocket request would be the first one seen by the server. Below is a successful example of this scenario using Firefox 11. In the same scenario, Chrome fails to respond to the 401 request.  

Websocket request from Browser:
GET /jsondata HTTP/1.1
Host: xxx.xxx.xxx.xxx/11080
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20100101 Firefox/11.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive, Upgrade
Sec-WebSocket-Version: 13
Origin: null
Sec-WebSocket-Key: xxxxxxxxxxxxxxxxxxx
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket

Sever response (with cookie) requesting username/password:
HTTP/1.0 401 Authorization Required
WWW-Authenticate: Basic realm="HomeVision"
Server: HomeVision/2.2.2 (HomeVisionXL)
Date: Sat, 21 Apr 2012 18:55:08 GMT
Expires: Sat, 21 Apr 2012 18:55:08 GMT
Connection: close
Set-cookie: HomeVisionAuthorization=xxxxxxxxxxxxxxxxxx; max-age=300
Content-Type: text/html
<html><body><h1>401 - Unauthorized access</h1>
<p>You are not authorized to browse these pages<p>
</body></html>

User enters username/password, browser makes new request with authorization/cookie info
GET /jsondata HTTP/1.1
Host: xxx.xxx.xxx.xxx/11080
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20100101 Firefox/11.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive, Upgrade, Upgrade
Sec-WebSocket-Version: 13
Origin: null
Sec-WebSocket-Key: xxxxxxxxxxxxxxxxxxx
Authorization: Basic xxxxyyyyzzzz
Pragma: no-cache, no-cache
Cache-Control: no-cache, no-cache
Upgrade: websocket
Cookie: HomeVisionAuthorization=xxxxxxxxxxxxxxxxxx

Server completes websocket:
HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Accept: xxxxxxxxxxxxxxxxxx
Server: HomeVision/2.2.2 (HomeVisionXL)

Comment 3 Deleted

Running a similar scenario but with certificates instead of basic username/password auth results in the same websocket failure - websocket closes immediately with a 1006 code. So I suspect something more fundamental going on here than just not supporting Basic Auth.
Although the protocol specification doesn't explicitly require including the "Authorization"-header, I think this is the expected behaviour. The protocol (RF6455) mentions the header on page 18:

   12.  The request MAY include any other header fields, for example,
        cookies [RFC6265] and/or authentication-related header fields
        such as the |Authorization| header field [RFC2616], which are
        processed according to documents that define them.

As Chrome does send cookies, I have a hard time thinking of a reason not to include basic auth headers. It would be very much appreciated if one of the official WebKit developers could reply to this issue.

(And I can confirm this behaviour on Chrome 18.0.1025.168 / Linux.)
Blockedon: 116624
Cc: bashi@chromium.org
Status: Available
On page 19, RFC6455 also say:

1.  If the status code received from the server is not 101, the
       client handles the response per HTTP [RFC2616] procedures.  In
       particular, the client might perform authentication if it
       receives a 401 status code; the server might redirect the client
       using a 3xx status code (but clients are not required to follow
       them), etc.  Otherwise, proceed as follows.

So we will support basic authentication. But it will not appear soon because this change depends on our going structural changes to support multiplexing.

Comment 7 by Deleted ...@, May 10 2012

The Authorization header allows for more than just basic authentication, please do not forget about Digest Authentication and Negotiate (i.e. SPNEGO).

Summary: Websocket upgrade handshake does not handle HTTP status 401
Ok, I change the subject to support others.

Comment 9 by ricea@chromium.org, Feb 15 2013

Blockedon: -chromium:116624 chromium:116624
Cc: ricea@chromium.org
Project Member

Comment 10 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Area-WebKit -WebKit-WebSockets Cr-Content Cr-Content-WebSockets
Project Member

Comment 11 by bugdroid1@chromium.org, Apr 6 2013

Labels: -Cr-Content Cr-Blink
Project Member

Comment 12 by bugdroid1@chromium.org, Apr 6 2013

Labels: -Cr-Content-WebSockets Cr-Blink-WebSockets
hi, will this be fixed anytime soon. last update was more than a year back. FireFox, even IE handles this properly, while chrome websocket fails to authenticate.

Comment 14 by Deleted ...@, Jul 8 2013

any word on progress or ETA of fixing this? can it be done without refactoring the whole websocket stack as per the blocking issue?
Hi, would like to know if this issue is being worked on. Thanks!

Comment 16 by ricea@chromium.org, Jul 23 2013

Blockedon: chromium:226931
The new implementation is under active development. There is a new tracking bug at  crbug.com/226931 

Comment 17 by Deleted ...@, Aug 28 2013

What version of Chrome is targeted for this one? Its not fixed in the latest (v29.0.1547.57 m) that I can confirm.

Comment 18 by Deleted ...@, Oct 15 2013

Same problem here. HTTP basic auth + WebSockets work fine with FF and MSIE, but not with Chromium (32.0.1672.0 (228662)) nor Google Chrome (30.0.1599.66).

PS: We have setup a little test for basic auth. Hope it works for you too: http://wstest.dlnode.com/

Comment 19 by Deleted ...@, Nov 11 2013

I experience same Problem with Chrome Version 30.0.1599.114 on Ubuntu with nginx basic auth + Websocket.
Same problem here. I am using Chrome Version 31.0.1650.57
I really can't believe I broke my neck over this.
Google congrats.
Same problem here, with windows auth. Using Chrome 32.0.1700.76.

Comment 23 by xabh...@gmail.com, Jan 30 2014

Is there any expected time by which this issue will be fixed?
2+ years, I think this thread is dead?

Comment 25 Deleted

It shouldn't be. The problem is still not solved. It's beyond me why this is taking so long, when the competition has handled the issue for a long time now.

Comment 27 by myrd...@gmail.com, May 17 2014

Bugs don't stop being bugs just because they are old. They stop being bugs when they are fixed. Considering the importance of this in many business applications, I'm surprised it is taking so long.

Comment 28 by ricea@chromium.org, Jun 12 2014

This should be fixed in the latest dev builds. Please test.

Comment 29 by gaut...@gmail.com, Jun 12 2014

Tested this on Version 37.0.2045.4 canary using SignalR with windows auth. It fails after about 5 seconds, falling back to serverSentEvents. Frames tab says: 'WebSocket is closed before the connection is established'.

Comment 30 by myrd...@gmail.com, Jun 13 2014

I tested with Canary 37.0.2046.0, connecting to an internally hosted web service  (iSupport) that uses web sockets over an NTLM authenticated HTTPS session. The web sockets failed to connect; they succeed in IE and FF.

Thank you for your attempt. If you have a specific site or service that provides more detailed results that would assist you I would be happy to connect to it to test.

Comment 31 by ricea@chromium.org, Jun 13 2014

gautelo, myrddin, thank you for taking the time to test and provide feedback. Unfortunately, Chrome doesn't yet support Windows/NTLM/SPNEGO authentication with WebSockets. It is a special case because it is stateful.

I was unable to find out whether anyone was using this kind of authentication with WebSockets or whether other browsers supported it, so your feedback is very useful.

Comment 32 by char...@kx.com, Jun 13 2014

Thanks for trying to fix this. I tried Version 37.0.2046.3 canary with kdb+3.2t (which passes all the latest autobahn tests, and this scenario works with FF)

Chrome sent
GET / HTTP/1.1\r\nHost: localhost:5000\r\nConnection: Upgrade\r\nPragma: no-cache\r\nCache-Control: no-cache\r\nUpgrade: websocket\r\nOrigin: http://127.0.0.1:5000\r\nSec-WebSocket-Version: 13\r\nUser-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2046.3 Safari/537.36\r\nAccept-Encoding: gzip,deflate,sdch\r\nAccept-Language: en-US,en;q=0.8\r\nSec-WebSocket-Key: WXkVCndtyCIWOMAGAu6Mtg==\r\nSec-WebSocket-Extensions: permessage-deflate; client_max_window_bits\r\n\r\n

Server replied
HTTP/1.1 401 Unauthorized\r\nConnection: close\r\nContent-Length: 0\r\nWWW-Authenticate: Basic realm=\"\"\r\n\r\n

and then nothing - no prompting for username/password.

Comment 33 by ricea@chromium.org, Jun 13 2014

charlie, had you already entered login credentials for http://localhost:5000 ? Chrome won't popup a login box for a WebSocket (or any other subresource, such as images) if it doesn't already have cached credentials.

So for order for WebSocket basic auth to work in Chrome, the main page (or some previous page) must have already authenticated to the same server in the same session.

If you had already entered username and password, then you've hit an unknown bug. If possible, it would be useful for us to have a net log. See the page https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details for how to collect one.

Comment 34 by char...@kx.com, Jun 13 2014

Thanks for the hints. Yes, it was using cached credentials for the ws.html page, and  Authorization: Basic [..] is visible in that request, but for some reason chrome is not submitting the Authorization: Basic […] field for the websocket upgrade request. Attached is requested log.
basic.log
309 KB View Download

Comment 35 by ricea@chromium.org, Jun 13 2014

charlie, I think I see the problem. You are accessing the server as http://127.0.0.1:5000/ for HTTP, but ws://localhost:5000/ for WebSockets. Chrome sees these as being different servers, and so doesn't use the cached credentials.

If you try accessing the server as http://localhost:5000/ then hopefully it will work.

Sorry for the confusion. Fortunately this sort of problem comes up more often in testing than in production, although you could see it if for example people access your site as either http://www.example.com/ or http://example.com/ but your WebSockets are always addressed to ws://www.example.com/. If you wanted to be extra-careful you could construct your WebSocket URL using window.location.host.

Comment 36 by char...@kx.com, Jun 13 2014

I tried http://localhost:5000 but unfortunately it does not solve the problem - same result.

Comment 37 by Deleted ...@, Jun 13 2014

Hi

I have excaltly the same problem (Chrome 35.0.1916.153 / 2012R2 IIS8) (Intranet environment):
User opens a page (http://iknow-int/Service) (Integrated windows authentication)
Page opens a WebSocket connection (by SignlR framework) back to the server and Chrome gets a 401:

WebSocket connection to 'ws://iknow-int/Service/signalr/connect?transport=webSockets&connectionToken=...' failed: Error during WebSocket handshake: Unexpected response code: 401 

It seems that the Authorisation token/header is not included in the WS request
Cc: -bashi@chromium.org -ricea@chromium.org
Labels: -OS-Windows
Owner: ricea@chromium.org
Status: Assigned
Summary: WebSocket upgrade handshake does not handle HTTP status 401 (was: Websocket upgrade handshake does not handle HTTP status 401)

Comment 39 by n...@petrovits.net, Jun 26 2014

I can replicate the same issue on a new project we are developing as an intranet web application. Our application is configured to use Windows Authentication with Kerberos. We had to disable NTLM since our application requires ticket delegation for impersonation and logging into other servers Windows servers. 

When Chrome attempts a WebSocket connection it fails with the following error:
WebSocket connection to 'ws://Application.IntranetDomain/signalr/connect?transport=webSockets&clientProtocol=1.4&connectionToken=TokenReplacedWithThisText%3D%3D&connectionData=%5B%7B%22name%22%3A%22signalrhubname%22%7D%5D&tid=7' failed: Error during WebSocket handshake: Unexpected response code: 401 jquery.signalR-2.1.0.min.js

Using IE10 and IE11 we are able to establish WebSocket connections, but we would prefer to deploy the application to our user base as a Chrome Application. (using an icon launching Chrome with the -app parameter.)

Thankfully SignalR falls back to long polling and Chrome works OK with Kerberos authentication.

Please let me know if I can provide any more data. I am willing to assist testing a fix once support for authentication is added to Chrome WebSockets.

Thank you,
Nick
Project Member

Comment 40 by bugdroid1@chromium.org, Jul 10 2014

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8d7ed25ca422433e8e4c23262fde158019d1d565

commit 8d7ed25ca422433e8e4c23262fde158019d1d565
Author: ricea@chromium.org <ricea@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>
Date: Thu Jul 10 11:13:47 2014

Map WebSocket URL schemes to HTTP URL schemes for auth purposes.

This permits WebSocket connections to inherit credentials from HTTP pages, and
matches the behaviour of other browsers.

Design doc: https://docs.google.com/a/chromium.org/document/d/129rLtf5x3hvhP5rayLiSxnEjOXS8Z7EnLJgBL4CdwjI/edit

Also consider any 401 or 407 results that reach the WebSocketStream
URLRequest::Delegate to be unrecoverable errors.

Also ensure that the response headers are reported back to the renderer
when the developer tools are open and a 401 error happens.

BUG= 123862 

Review URL: https://codereview.chromium.org/336263005

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@282307 0039d316-1c4b-4281-b951-d872f2087c98


Project Member

Comment 41 by bugdroid1@chromium.org, Jul 10 2014

------------------------------------------------------------------
r282307 | ricea@chromium.org | 2014-07-10T11:13:47.083971Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/tools/testserver/testserver.py?r1=282307&r2=282306&pathrev=282307
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/websockets/websocket_basic_handshake_stream.cc?r1=282307&r2=282306&pathrev=282307
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/test/spawned_test_server/base_test_server.cc?r1=282307&r2=282306&pathrev=282307
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/test/spawned_test_server/base_test_server.h?r1=282307&r2=282306&pathrev=282307
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/data/websocket/README?r1=282307&r2=282306&pathrev=282307
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/net/websocket_browsertest.cc?r1=282307&r2=282306&pathrev=282307
   A http://src.chromium.org/viewvc/chrome/trunk/src/net/data/websocket/connect_to.html?r1=282307&r2=282306&pathrev=282307
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/websockets/websocket_stream_test.cc?r1=282307&r2=282306&pathrev=282307
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/websockets/websocket_stream.cc?r1=282307&r2=282306&pathrev=282307
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_network_transaction.cc?r1=282307&r2=282306&pathrev=282307
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/websockets/websocket_stream.h?r1=282307&r2=282306&pathrev=282307

Map WebSocket URL schemes to HTTP URL schemes for auth purposes.

This permits WebSocket connections to inherit credentials from HTTP pages, and
matches the behaviour of other browsers.

Design doc: https://docs.google.com/a/chromium.org/document/d/129rLtf5x3hvhP5rayLiSxnEjOXS8Z7EnLJgBL4CdwjI/edit

Also consider any 401 or 407 results that reach the WebSocketStream
URLRequest::Delegate to be unrecoverable errors.

Also ensure that the response headers are reported back to the renderer
when the developer tools are open and a 401 error happens.

BUG= 123862 

Review URL: https://codereview.chromium.org/336263005
-----------------------------------------------------------------
Project Member

Comment 42 by bugdroid1@chromium.org, Jul 10 2014

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ebe843d5ced1ebe145bb8d86b3eabb6fe5437ecc

commit ebe843d5ced1ebe145bb8d86b3eabb6fe5437ecc
Author: kaliamoorthi@chromium.org <kaliamoorthi@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>
Date: Thu Jul 10 15:18:44 2014

Revert 282307 "Map WebSocket URL schemes to HTTP URL schemes for..."

> Map WebSocket URL schemes to HTTP URL schemes for auth purposes.
> 
> This permits WebSocket connections to inherit credentials from HTTP pages, and
> matches the behaviour of other browsers.
> 
> Design doc: https://docs.google.com/a/chromium.org/document/d/129rLtf5x3hvhP5rayLiSxnEjOXS8Z7EnLJgBL4CdwjI/edit
> 
> Also consider any 401 or 407 results that reach the WebSocketStream
> URLRequest::Delegate to be unrecoverable errors.
> 
> Also ensure that the response headers are reported back to the renderer
> when the developer tools are open and a 401 error happens.
> 
> BUG= 123862 
> 
> Review URL: https://codereview.chromium.org/336263005

Seems to cause WebSocket1 failure in WinXP

TBR=ricea@chromium.org

Review URL: https://codereview.chromium.org/388493002

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@282331 0039d316-1c4b-4281-b951-d872f2087c98


Project Member

Comment 43 by bugdroid1@chromium.org, Jul 10 2014

------------------------------------------------------------------
r282331 | kaliamoorthi@chromium.org | 2014-07-10T15:18:44.822782Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/test/spawned_test_server/base_test_server.cc?r1=282331&r2=282330&pathrev=282331
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/test/spawned_test_server/base_test_server.h?r1=282331&r2=282330&pathrev=282331
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/data/websocket/README?r1=282331&r2=282330&pathrev=282331
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/net/websocket_browsertest.cc?r1=282331&r2=282330&pathrev=282331
   D http://src.chromium.org/viewvc/chrome/trunk/src/net/data/websocket/connect_to.html?r1=282331&r2=282330&pathrev=282331
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/websockets/websocket_stream_test.cc?r1=282331&r2=282330&pathrev=282331
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/websockets/websocket_stream.cc?r1=282331&r2=282330&pathrev=282331
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_network_transaction.cc?r1=282331&r2=282330&pathrev=282331
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/websockets/websocket_stream.h?r1=282331&r2=282330&pathrev=282331
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/tools/testserver/testserver.py?r1=282331&r2=282330&pathrev=282331
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/websockets/websocket_basic_handshake_stream.cc?r1=282331&r2=282330&pathrev=282331

Revert 282307 "Map WebSocket URL schemes to HTTP URL schemes for..."

> Map WebSocket URL schemes to HTTP URL schemes for auth purposes.
> 
> This permits WebSocket connections to inherit credentials from HTTP pages, and
> matches the behaviour of other browsers.
> 
> Design doc: https://docs.google.com/a/chromium.org/document/d/129rLtf5x3hvhP5rayLiSxnEjOXS8Z7EnLJgBL4CdwjI/edit
> 
> Also consider any 401 or 407 results that reach the WebSocketStream
> URLRequest::Delegate to be unrecoverable errors.
> 
> Also ensure that the response headers are reported back to the renderer
> when the developer tools are open and a 401 error happens.
> 
> BUG= 123862 
> 
> Review URL: https://codereview.chromium.org/336263005

Seems to cause WebSocket1 failure in WinXP

TBR=ricea@chromium.org

Review URL: https://codereview.chromium.org/388493002
-----------------------------------------------------------------
Project Member

Comment 44 by bugdroid1@chromium.org, Jul 29 2014

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e69c1cd33dee41835499a5130c3431a059b4ac7d

commit e69c1cd33dee41835499a5130c3431a059b4ac7d
Author: ricea@chromium.org <ricea@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>
Date: Tue Jul 29 07:42:29 2014

Map WebSocket URL schemes to HTTP URL schemes for auth purposes.

This permits WebSocket connections to inherit credentials from HTTP pages, and
matches the behaviour of other browsers.

Design doc: https://docs.google.com/a/chromium.org/document/d/129rLtf5x3hvhP5rayLiSxnEjOXS8Z7EnLJgBL4CdwjI/edit

Also consider any 401 or 407 results that reach the WebSocketStream
URLRequest::Delegate to be unrecoverable errors.

Also ensure that the response headers are reported back to the renderer
when the developer tools are open and a 401 error happens.

BUG= 123862 

Review URL: https://codereview.chromium.org/336263005

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@286108 0039d316-1c4b-4281-b951-d872f2087c98


Project Member

Comment 45 by bugdroid1@chromium.org, Jul 29 2014

------------------------------------------------------------------
r286108 | ricea@chromium.org | 2014-07-29T07:42:29.835274Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/test/spawned_test_server/base_test_server.cc?r1=286108&r2=286107&pathrev=286108
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/test/spawned_test_server/base_test_server.h?r1=286108&r2=286107&pathrev=286108
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/data/websocket/README?r1=286108&r2=286107&pathrev=286108
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/net/websocket_browsertest.cc?r1=286108&r2=286107&pathrev=286108
   A http://src.chromium.org/viewvc/chrome/trunk/src/net/data/websocket/connect_to.html?r1=286108&r2=286107&pathrev=286108
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/websockets/websocket_stream_test.cc?r1=286108&r2=286107&pathrev=286108
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/websockets/websocket_stream.cc?r1=286108&r2=286107&pathrev=286108
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_network_transaction.cc?r1=286108&r2=286107&pathrev=286108
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/websockets/websocket_stream.h?r1=286108&r2=286107&pathrev=286108
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/tools/testserver/testserver.py?r1=286108&r2=286107&pathrev=286108
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/websockets/websocket_basic_handshake_stream.cc?r1=286108&r2=286107&pathrev=286108

Map WebSocket URL schemes to HTTP URL schemes for auth purposes.

This permits WebSocket connections to inherit credentials from HTTP pages, and
matches the behaviour of other browsers.

Design doc: https://docs.google.com/a/chromium.org/document/d/129rLtf5x3hvhP5rayLiSxnEjOXS8Z7EnLJgBL4CdwjI/edit

Also consider any 401 or 407 results that reach the WebSocketStream
URLRequest::Delegate to be unrecoverable errors.

Also ensure that the response headers are reported back to the renderer
when the developer tools are open and a 401 error happens.

BUG= 123862 

Review URL: https://codereview.chromium.org/336263005
-----------------------------------------------------------------

Comment 46 by hup...@gmail.com, Aug 13 2014

I made a SignalR test with version 2.1.1. Bug is still there. Really funny... Internet Explorer can handle it ;)
When I submitted this  issue 2  years and 4 months ago, Firefox was the only browser that supported basic auth with websockets. Somewhere between then and now, IE began supporting it as well. Now it is just Chrome that doesn't.

But I am thankful that someone is now finally trying to get this to work!

Comment 48 Deleted

myrddin, are you sure that the WebSocket is prompting for authentication? It's not supposed to. It's supposed to inherit the authentication from HTTP(S). The host and port must match, ie. wss://example.com:8443/ will inherit authentication credentials from https://example.com:8443/ but not from https://example.com/.

NTLM support is a known gap. It's scheduled for implementation, but I cannot make any guarantees about when.

Comment 50 by myrd...@gmail.com, Oct 9 2014

I deleted my comment #48, because I was wrong; the behavior I saw in 38 is not wss:// related (that's still flat-out failing).
I am not seeing this work with Negotiate in Chrome Version 38.0.2125.101. 

IE11 is able to connect using web sockets, but Chrome is not.

Chrome still fails with the following error message:
WebSocket connection to 'ws://signalr.[redacted]:8080/signalr/connect?transport=webSockets&clientProtocol=1.4&connectionToken=[redacted]&connectionData=%5B%7B%22name%22%3A%22[redacted]%22%7D%5D&tid=8' failed: HTTP Authentication failed; no valid credentials available 

The web url for the site is:
http://[redacted]:8080/

Note, that this is different then signalr.[redacted]:8080. The SignalR endpoint has a unique dns name for performance. This way a socket isn't used up if the client doesn't support web sockets. (As some browsers have a very low socket limit per domain.)
Extending on post #51...

I have confirmed that changing my SignalR Url will allow this to work with the value:
'ws://[redacted]:8080/signalr'

Sadly, this is not a feasible production url for us, and it must be:
'ws://signalr.[redacted]:8080/signalr'

Comment 53 by Deleted ...@, Oct 13 2014

Extending on post #52…

I am using the same url for both the web site and ws, but am still getting the same issue with HTTP Authentication failed; no valid credentials.

Comment 54 by Deleted ...@, Oct 13 2014

Please fix this bug 
As the original poster of this  bug 2 .5 years ago, I've just about given up hope that this will ever get fixed properly. In any case, I tell all my web server users to use FireFox, which works fine. Too bad Chrome can't get its act together with this bug.

Comment 56 Deleted

Please Fix
Please fix this bug

Comment 59 by nppes...@gmail.com, Oct 13 2014

please fix this bug
Please fix

Comment 61 by Deleted ...@, Oct 13 2014

Please fix

This is a very basic functionality that should work. It would be very much appreciated if it can be resolved,
please fix

Comment 64 by Deleted ...@, Oct 14 2014

Please fix the reported bug!

Comment 65 by ricea@chromium.org, Oct 15 2014

Status: Fixed
Please do not make information-free comments such a "please fix". Specific information such as products or services which are impacted, and number of users affected are useful. Network logs of authentication failures as described in http://dev.chromium.org/for-testers/providing-network-details are very useful.

I am closing this issue as HTTP status 401 is now supported. I have created a new issue for Windows authentication support: crbug.com/423609
 Issue 433608  has been merged into this issue.
For us non-developers, what (released) version of chrome has this fixed? As the OP, I'd like to test this, but don't have the ability to build a Windows version

Comment 68 by tkent@chromium.org, Nov 27 2015

Labels: Cr-Blink-Network-WebSockets

Comment 69 by tkent@chromium.org, Nov 27 2015

Labels: -Cr-Blink-WebSockets
This still doesn't work if websocket server is behind VPN.
Tested on Dell Sonicwall virtual appliance.

Create a bookmark and enabled SSO (this will use HTTP Basic Auth).

The url for the browser 

https://192.168.100.1/go/http://192.168.12.110/example12.html

(internal url is http://192.168.12.110/example12.html):

There are two problems on this:

1. When you create a websocket on this page wss://192.168.100.1/go/http://192.168.12.110
The Authorization header is not set.

2. When the server return 401 during the WebSocekt handshake. There is no credential dialog displayed as usual and websocket is simply closed.

This wouldn't happen if you access the internal web address.

Firefox also have issue 1, but credential dialog is displayed and Authorization header will be set after.

You can download Sonicwall virtual appliance to test this.

http://support-public.cfm.software.dell.com/25879_sra_virtual_appliance_getting_started_guide.pdf

I believe this should happen on Cisco, Juniper and other VPN applicane too because they use same kind of URL.




sonicwall.PNG
60.4 KB View Download

Comment 71 by ricea@chromium.org, Dec 21 2015

#70: It sounds like Chrome does not believe it has cached credentials matching this connection. Chrome will never display an authentication dialogue for a WebSocket connection.

It might be possible for me to diagnose further if you send me a network log as described in https://dev.chromium.org/for-testers/providing-network-details but it will have to contain credential information which may not be desirable.
The network log file was attached

net-internals-log.json
527 KB Download

Comment 73 by ricea@chromium.org, Jan 15 2016

#72 yongtao: Sorry for the slow response.

This server appears to use cookie-based authentication for HTTPS requests and only use HTTP Basic authentication for WSS requests. This won't work with Chrome because it doesn't display authentication dialogues for WebSocket connections. If the user hasn't already entered their credentials.

I'm not sure whether the VPN is making any difference. Perhaps the original server always used Basic auth but the VPN translates it into cookie-based auth for HTTPS, but not for WSS?

If that is the case, then the VPN needs to use the same authentication method for both HTTPS and WSS.

You could open a new bug asking for authentication UI to be shown for WebSocket requests, and our UI people would look at it, but the decision not to popup a login/password box probably won't change.
Thanks a lot for your response which is actually fast considering we are in holiday season.
I'm having this same problem on Safari 9.0.3 (11601.4.4) although current Chrome and Firefox work as expected.  Has anyone else here seen problems with Safari and perhaps knows of a ticket referring to it?  I can't find anything online.
This bug seems to still exist, are there any plans to address it in the near future?

Comment 77 by ricea@chromium.org, Apr 14 2017

#76 This is fixed. We have tests in place to ensure that it does not stop working.

If you have an issue where authentication is not working in Chrome but works in other browsers, please file a new bug.

Sign in to add a comment