Usernames and passwords can be added to links to resources (and images) which aren't necessarily protected by authorization, and in that sense can be used as a "cookie" of sorts to track users irrespective of cookie settings. It's a bit hokey, but I've heard of it being done before (more than once, actually). Try it on your Web server, and dump the headers for your image request after you serve this:
OK that seems like the sort of situation you'd want some sort of privacy controls in but this bug is about it getting ignored when you type it into the URL bar yourself right?
The ipad browser pops up a red phishing warning when you access a bookmark(!) that has credentials in the URL.
This is royally annoying because the same browser can't save these credentials otherwise.
So for sites using simple/digest-auth you're given the choice
between typing in your password every time, or getting that stupid warning dialog every time.
What's wrong with a browser allowing an auth URL to be typed directly into the address bar or clicked from a Bookmark, but disallow it in any other form?
I'm providing a reason for the change, not a reason for Chrome's particular choice. Not trying to debate the bug itself, just providing a reason that it was addressed.
If those rewriting rules have to be server-side, and I think that's what you mean, the answer to that is that browsers don't get to dictate terms to servers that way; browsers can say what they will and won't accept, especially in terms of content type, but URI format isn't generally something the browser can specify.
Once the URL is "learned", the credentials will continue to be sent. Replicate that with query strings...
Edit: Thanks for deleting instead of just admitting you were, in this case, wrong. The comment here that I originally replied to called me wrong and said that query strings are equally efficient for this purpose.
Comments
Reason for this everybody is overlooking:
Usernames and passwords can be added to links to resources (and images) which aren't necessarily protected by authorization, and in that sense can be used as a "cookie" of sorts to track users irrespective of cookie settings. It's a bit hokey, but I've heard of it being done before (more than once, actually). Try it on your Web server, and dump the headers for your image request after you serve this:
<img src="http://cookiedata@example.com/image.gif>;
doesn't matter , firefox show up a confirmation dialog when u click that link or load it via a page (unspoofable dialog, btw)
anyway, the fix is easy. just use firefox, again. it's actually pretty fast 'n all now ;-)
same in opera.
OK that seems like the sort of situation you'd want some sort of privacy controls in but this bug is about it getting ignored when you type it into the URL bar yourself right?
The ipad browser pops up a red phishing warning when you access a bookmark(!) that has credentials in the URL.
This is royally annoying because the same browser can't save these credentials otherwise.
So for sites using simple/digest-auth you're given the choice between typing in your password every time, or getting that stupid warning dialog every time.
Good work, Apple. That is truly "magical".
As far as I understand it's actually been deprecated and being treated as not a bug by the chrome team
What's wrong with a browser allowing an auth URL to be typed directly into the address bar or clicked from a Bookmark, but disallow it in any other form?
I'm providing a reason for the change, not a reason for Chrome's particular choice. Not trying to debate the bug itself, just providing a reason that it was addressed.
What benefit does that have over a unique path/param?
because the browser will always send the unique username to anything at that domain and path
But you could just as easily do:
With just a few rewriting rules.If those rewriting rules have to be server-side, and I think that's what you mean, the answer to that is that browsers don't get to dictate terms to servers that way; browsers can say what they will and won't accept, especially in terms of content type, but URI format isn't generally something the browser can specify.
[deleted]
Once the URL is "learned", the credentials will continue to be sent. Replicate that with query strings...
Edit: Thanks for deleting instead of just admitting you were, in this case, wrong. The comment here that I originally replied to called me wrong and said that query strings are equally efficient for this purpose.