Re: [hybi] Authentication headers
Ian Hickson <ian@hixie.ch> Wed, 21 July 2010 07:01 UTC
Return-Path: <ian@hixie.ch>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C59C3A677C for <hybi@core3.amsl.com>; Wed, 21 Jul 2010 00:01:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.307
X-Spam-Level:
X-Spam-Status: No, score=-2.307 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5tKWAX6SkeN for <hybi@core3.amsl.com>; Wed, 21 Jul 2010 00:01:15 -0700 (PDT)
Received: from looneymail-a1.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id 4AD313A697A for <hybi@ietf.org>; Wed, 21 Jul 2010 00:01:15 -0700 (PDT)
Received: from ps20323.dreamhostps.com (ps20323.dreamhost.com [69.163.222.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by looneymail-a1.g.dreamhost.com (Postfix) with ESMTP id 8385815D565; Wed, 21 Jul 2010 00:01:31 -0700 (PDT)
Date: Wed, 21 Jul 2010 07:01:31 +0000
From: Ian Hickson <ian@hixie.ch>
To: Wellington Fernando de Macedo <wfernandom2004@gmail.com>
In-Reply-To: <AANLkTimo9g4Tvzd1RekVXKtTpOhRz58jr7VLqhS-Wrdf@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1007210653190.7242@ps20323.dreamhostps.com>
References: <AANLkTimo9g4Tvzd1RekVXKtTpOhRz58jr7VLqhS-Wrdf@mail.gmail.com>
Content-Language: en-GB-hixie
Content-Style-Type: text/css
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Cc: hybi@ietf.org
Subject: Re: [hybi] Authentication headers
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Jul 2010 07:01:17 -0000
On Mon, 7 Jun 2010, Wellington Fernando de Macedo wrote: > > I'm updating the Mozilla's implementation of the WS protocol to its > latest version (v.76). I know that handling the 401 http response was > already removed in the v75. But now I've noted that even the http > Authorization header has been removed. > > Well, I think that the 401 http status was removed in order to prevent > the browser to open unexpected auth dialogs to the user. Actually, I > know there is the cookie information, but I think it isn't always > enough. So, I would like to ask, why can't a "normal" request include > the Authorization header from its page origin? There's some commented-out text to that effect, but frankly it's not clear to me that it would be particularly useful in practice. For example, the only authentication scheme that would work and be secure is Basic auth over TLS to the same host as served the HTML page. In practice, only very few sites use that combination of technologies; the cost of supporting it seems higher than the benefit gained from it. It also seems unreliable; it relies on the browser remembering the credentials used when loading the Web page, for instance. There are also a number of situations where it would seem that it should work but where it won't, for example if a page on one path uses pushState() to go to another path and then opens a WebSocket connection to the same host with the second path, the UA would not know the realm of the second path and thus wouldn't know to include the authentication information. Basically, it seemed hacky. I couldn't really find a compelling argument to support this rather than having it at the application layer. (You can still leverage the basic auth feature that way, just have the server send back a unique token that identifies the user's session and then pass that back on the WebSocket connection.) Cookies are supported because they are _very_ widely used, so there's something to reuse. HTTP auth is used so rarely that I'd seriously consider dropping it from HTTP at this point; I really don't think it's worth adding to WebSockets. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
- [hybi] Authentication headers Wellington Fernando de Macedo
- Re: [hybi] Authentication headers Wellington Fernando de Macedo
- Re: [hybi] Authentication headers Ian Hickson
- Re: [hybi] Authentication headers Daniel Stenberg
- Re: [hybi] Authentication headers Greg Wilkins
- Re: [hybi] Authentication headers Wellington Fernando de Macedo
- Re: [hybi] Authentication headers Wellington Fernando de Macedo
- Re: [hybi] Authentication headers Wellington Fernando de Macedo
- Re: [hybi] Authentication headers Greg Wilkins