Unless you start saying something instead of just ignoring everything I
say, I don't see much point to continuing this useless thread.
In <35079B6C.A39DC...@cyberhighway.net> Bill Anderson <ucnt...@cyberhighway.net> writes:
>> >No, I fully know what is going on.
>> >Actually, in IE when you are asked for authentication to a site, it also asks
>> >if you want it to remeber the user/pass pair, so, no it is not the default.
>> That has nothing to do with what I am talking about.
>But it has to do with the original question. And, yes it is quite relevant, see
>below for why.
>Now, if you are not talking about what the original post was, that statement
>may be true ;)
>> >Besides, Michael said "both servers use the same authentication realm" so it is
>> >not a case of different info for a different server. On some of my servers I
>> All the realm is is a locally (ie. per server, including port) unique
>> string that identifies the protected area. It is not unique
>> across servers, across different ports on the same host, etc.
>But you set it in the configuration. If someone has access to what *you*
>configure your realm name (or 'string' if you prefer), they can get your
>user/pass pair regardless of browser.
Complete and total bullshit.
To find out what the realm name is, all you have to do is try accessing
a restricted page on the site. Just having that realm name does _NOT_
let you do anything because the client must not send it to a
different server. As I have said, they have a _local_ namespace to the
server, not a global one. Please go read the damn standards and learn
how HTTP works before claming such things.
What you are saying there is that the client will send the cached
auth info to _ANY_ server that asks for it. Even IE isn't broken enough
to pull that crap. Well, not in most versions.
>> and if you exit Navigator so that no password information is cached, then
>> visit the first one, authenticate, then visit the second one you will
>> gain access to the second one without entering a name or password?
>No, I did just what was posted originally, I go from one to the other without
>quitting Netscape, as it was not stated one was quitting either NS or MSIE.
>That would make a difference. I made no assumption that the browsers were
>closed before accessing sites.
The point in exiting the client first is to be sure you don't have
cached authentication information. Please do not put words in
my mouth. Stop and read what I said.
>In my case, I have a link on SiteA that points to SIteB. Both are restricted,
>on different ports, and I can go from one to the other seamlessly. that is
>desirable, and it works. So far, the only difference I can see that is
>different (lacking config details of course) is that both of mine are Apache
The server is irrelevant.
>> >Thus, depending upon how it was implemented, it is something in his
>> >configuration that Netscape is not playing properly with. If mine under
>> >Netscape works as his under IE, then if IE is broken, so is Netscrape. Much to
>> >my dismay, Netscape's browsers fail to follow the standards as well as
>> >Microslough's browser does. Hopefully, once we get the source, we can fix that
>> I think you are misunderstanding the issue here. Please read what
>> I write.
>I could say the same to you, sir.
You could but, like most of the rest of what you are saying, you would
>> >I have plenty of knowledge on how the web works. And you said it was broken
>> >because it did it by default:
>> >> No, the problem is what IE is doing by default.
>> >> The problem
>> >> is that doing it by default is completely broken
>> >So, by you did claim it is broken for a default action. In actuality, the
>> >default is for it to ask you if you want it to 'remember' for you. What could
>> >be described as broken is that there is no way, AFAIK, for it to be told to
>> >'forget'. That is broken.
>> NO! You are missing the point. Read what I write instead of
>> just saying I am wrong.
>I QUOTED YOU! YOU specifically said:
>>No, the problem is what IE is doing by default.
>>The problem is that doing it by default is completely broken
>Now, by English rules, you said the problem is that IE does it by default, and
>that it was broken for it to do so. Now, if you wish to claim you never said
>that, that is another matter.
>Read what you wrote, I did.
>BTW that was from a single post...with your name on it ...
Erm... why the hell do you think you can take my words, take them out
of context, and claim they apply to something completely different
than they do?
I am talking about the behaviour of sending the same auth info to
a server on a different port. The problem is that IE is doing it
by default. Doing it by default is completely broken. I have no
idea where you are making up the idea that I am talking about
>It is not a broken attempt. It is a frequently used technique. It also shows
>the original poster yet another method of doing what he wants.
That's nice, but it has nothing to do with the issue! You are trying to
claim that clients send cached basic authentication information to
different servers by not using basic auth!?!
>> It appears you don't understand that, which is fine since everyone
>> has to learn somehow, and are unwilling to learn, which isn't fine.
>> While I can be a cocky bastard (albeit generally a knowledgeable
>> cocky bastard), it is normally because I tend to be correct quite
>> often for some reason and am getting quite tired of someone trying
>> to bluster their way through a discussion without knowing facts
>> and trying to confuse the issue by introducing irrelevant issues.
>Well, it seems in this case you misunderstood the original post, and therein
>lies the bone of contention. Nothing was ever said abouot closing IE or NS and
>then trying to access the other site. And since I can do the same thing he
You are right, you are the only one trying to bring in restarting
the client between accessing the sites.
>does, and do it in NS, there is a flaw somewhere in your argument that because
>MS does it, it is broken and not following the standards, and NS is not. I
>leave it to you to find it.
I'm afraid that I have trouble accepting your results for several reasons.
First, you have demonstrated that you don't have a clue about how
HTTP works in several issues here. Second, it does not work for me
using Navigator 4.x. Third, the standards say quite clearly that it
must not work.
>I too can be a stubborn bastard, for the same reasons you can be a cocky
The difference is that you ignore everything I write while I read what
you write and get sick of trying to repeatedly correct you.
>Look, the issue is whether or not a given browser is broken because it sends a
>response (user/pass) to an authentication request, and whether that action is a
>It was claimed that if such exists, one could configure yet another server on
>say, port 8082, and get people to go to your rogue server and get user/pass
>pairs all day long. Well, if the user is going to the rogue site, thinking he
>is going to the normal, secure site, you will get his user/pass regardless of
>whether the browser caches it or not. If it does not, he will manually type
>them in, and you will get them. Now, unless you have access to the database he
>is to authenticate against, he will fail. You still get the goods though. Of
>course, if the rogue has access to your security database, you have bigger
>problems than a caching browser.
>That is my point.
You are missing the key point. They do not go to the other page
_thinking_ they are going to the same site. They know damn well they
are going to a different one. If their broken client sends the cached
auth information to another server, then that other server will get it
without them knowing, without them having to enter it (or not enter
it because they know they shouldn't have to, in thise case), etc.
You are trying to argue that because someone could go somewhere
and enter their auth info explicitly when anyone asks for it that is
the same thing as their client automatically giving it away without
them knowing or being able to stop it. That is nonsense.
>Now, if you can shut down MSIE and still have it not rechallenge, I would say
>it is broken (but, OTOH, 4.04 will only make me reauthenticate 3 times before
>it does it for me. To get it to stop doing that, I clear memory and disk cache,
>very annoying, and very broken IMO). Care to express a bit more detail,
As I have said before, that is completely irrelevant. You can make up
whatever you want, but it has nothing to do with the issue.
The issue is if MSIE is broken because it treats webservers on different
ports on the same host as having the same namespace for auth
realms. You start by making wild claims that because doing so does
what someone wants to do, it isn't fair to judge. Bullshit. The
standards are there, the security risks are obvious. Then you go
on to introduce all sorts of irrelevant things (eg. cookies,
saving auth info to persistent storage, etc.) and ignore everything
I write while demonstrating your ignorance of the way HTTP works
(eg. claiming that using different sources of auth info on the server
make it different, claiming that having the realm name will let you get
the auth info, etc). Sheesh.