Re-enable embedded identities in URLs for HTTP authentication.

Re-enable embedded identities in URLs for HTTP authentication.

This effectively reverts r121506.

BUG=123150
TEST=net_unittests. Username/passwords specified in URLs work. XmlHttpRequests() with credentials passed as arguments work.

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=138264

[asanka, 2012-05-21 21:47:51]

Excludes restoring HttpNetworkTransaction unit tests for now.

[asanka, 2012-05-21 23:37:42]

HttpNetworkTransaction*Tests added.

I manually verified that identities specified via arguments to XHR work, but I
didn't add a unit test for that case yet.

[cbentzel, 2012-05-22 01:18:04]

I wish this was a simpler revert. Seems good, looking again.

[cbentzel, 2012-05-22 01:37:00]

LGTM

[asanka, 2012-05-22 02:06:05]

Thanks. I'll put this on the CQ once the win_rel try job goes through.

This should apply to M20. We'll have to do a separate revert for M19.

[commit-bot: I haz the power, 2012-05-22 06:53:02]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/asanka@chromium.org/10412025/7001

[commit-bot: I haz the power, 2012-05-22 09:26:29]

Try job failure for 10412025-7001 (retry) on win_rel for steps "base_unittests,
sync_unit_tests".
It's a second try, previously, steps "base_unittests, sync_unit_tests" failed.
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win_rel&nu...

[jschuh, 2013-02-12 10:17:39]

This change was done without consulting the security team and introduced a
security regression crbug.com/174129  I intend on reverting it tomorrow unless
there's some reasonable justification, which is lacking from the discussion in
crbug.com/123150

[asanka, 2013-02-12 16:08:00]

On 2013/02/12 10:17:39, Justin Schuh wrote:
> This change was done without consulting the security team and introduced a
> security regression crbug.com/174129  I intend on reverting it tomorrow unless
> there's some reasonable justification, which is lacking from the discussion in
> crbug.com/123150

The change was discussed as mentioned in
http://code.google.com/p/chromium/issues/detail?id=123150#c69.  It was done to
restore support in XHR for passing explicit credentials. I'll comment on
crbug.com/174129 regarding this.

[jschuh, 2013-02-12 16:27:27]

On 2013/02/12 16:08:00, asanka wrote:
> On 2013/02/12 10:17:39, Justin Schuh wrote:
> > This change was done without consulting the security team and introduced a
> > security regression crbug.com/174129  I intend on reverting it tomorrow
unless
> > there's some reasonable justification, which is lacking from the discussion
in
> > crbug.com/123150
> 
> The change was discussed as mentioned in
> http://code.google.com/p/chromium/issues/detail?id=123150#c69.  It was done to
> restore support in XHR for passing explicit credentials. I'll comment on
> crbug.com/174129 regarding this.

Apparently the conversation was not interpreted the same by both sides. So, I'm
still inclined to revert this, and more so because this change left things in a
broken state.

[asanka, 2013-02-12 16:54:28]

On 2013/02/12 16:27:27, Justin Schuh wrote:
> On 2013/02/12 16:08:00, asanka wrote:
> > On 2013/02/12 10:17:39, Justin Schuh wrote:
> > > This change was done without consulting the security team and introduced a
> > > security regression crbug.com/174129  I intend on reverting it tomorrow
> unless
> > > there's some reasonable justification, which is lacking from the
discussion
> in
> > > crbug.com/123150
> > 
> > The change was discussed as mentioned in
> > http://code.google.com/p/chromium/issues/detail?id=123150#c69.  It was done
to
> > restore support in XHR for passing explicit credentials. I'll comment on
> > crbug.com/174129 regarding this.
> 
> Apparently the conversation was not interpreted the same by both sides. So,
I'm
> still inclined to revert this, and more so because this change left things in
a
> broken state.

Ah. Unfortunately allowing the use of explicit credentials with XHR would, I
think, lead to the same problem as described in crbug.com/174129. I'll open a
separate issue for figuring out how to resolve this in a safe manner.

[jschuh, 2013-02-12 17:09:08]

On 2013/02/12 16:54:28, asanka wrote:
> On 2013/02/12 16:27:27, Justin Schuh wrote:
> > On 2013/02/12 16:08:00, asanka wrote:
> > > On 2013/02/12 10:17:39, Justin Schuh wrote:
> > > > This change was done without consulting the security team and introduced
a
> > > > security regression crbug.com/174129  I intend on reverting it tomorrow
> > unless
> > > > there's some reasonable justification, which is lacking from the
> discussion
> > in
> > > > crbug.com/123150
> > > 
> > > The change was discussed as mentioned in
> > > http://code.google.com/p/chromium/issues/detail?id=123150#c69.  It was
done
> to
> > > restore support in XHR for passing explicit credentials. I'll comment on
> > > crbug.com/174129 regarding this.
> > 
> > Apparently the conversation was not interpreted the same by both sides. So,
> I'm
> > still inclined to revert this, and more so because this change left things
in
> a
> > broken state.
> 
> Ah. Unfortunately allowing the use of explicit credentials with XHR would, I
> think, lead to the same problem as described in crbug.com/174129. I'll open a
> separate issue for figuring out how to resolve this in a safe manner.

Please CC tsepez and add the Feature-Security flag. We should work out a
solution that doesn't revert the phishing protection but doesn't simplify XSRF.

[asanka, 2013-02-13 17:33:35]

On 2013/02/12 17:09:08, Justin Schuh wrote:
> On 2013/02/12 16:54:28, asanka wrote:
> > On 2013/02/12 16:27:27, Justin Schuh wrote:
> > > On 2013/02/12 16:08:00, asanka wrote:
> > > > On 2013/02/12 10:17:39, Justin Schuh wrote:
> > > > > This change was done without consulting the security team and
introduced
> a
> > > > > security regression crbug.com/174129  I intend on reverting it
tomorrow
> > > unless
> > > > > there's some reasonable justification, which is lacking from the
> > discussion
> > > in
> > > > > crbug.com/123150
> > > > 
> > > > The change was discussed as mentioned in
> > > > http://code.google.com/p/chromium/issues/detail?id=123150#c69.  It was
> done
> > to
> > > > restore support in XHR for passing explicit credentials. I'll comment on
> > > > crbug.com/174129 regarding this.
> > > 
> > > Apparently the conversation was not interpreted the same by both sides.
So,
> > I'm
> > > still inclined to revert this, and more so because this change left things
> in
> > a
> > > broken state.
> > 
> > Ah. Unfortunately allowing the use of explicit credentials with XHR would, I
> > think, lead to the same problem as described in crbug.com/174129. I'll open
a
> > separate issue for figuring out how to resolve this in a safe manner.
> 
> Please CC tsepez and add the Feature-Security flag. We should work out a
> solution that doesn't revert the phishing protection but doesn't simplify
XSRF.

FYI: Filed https://code.google.com/p/chromium/issues/detail?id=175836 yesterday.
As I noted in the bug, I don't believe reverting this is sufficient to resolve
174129 nor is it a regression.